From nobody Wed Nov 1 10:54:02 2017 Return-Path: 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 084E513F560 for ; Wed, 1 Nov 2017 10:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 ltj8AM-kztp2 for ; Wed, 1 Nov 2017 10:53:58 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECCD13F44C for ; Wed, 1 Nov 2017 10:53:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4AE492CFB1 for ; Wed, 1 Nov 2017 19:53:57 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAOIupwROUdT for ; Wed, 1 Nov 2017 19:53:56 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id A42C22CCC0 for ; Wed, 1 Nov 2017 19:53:56 +0200 (EET) (envelope-from jari.arkko@piuha.net) From: Jari Arkko Content-Type: multipart/alternative; boundary="Apple-Mail=_94BFC48F-3D42-4348-B69F-47B89512A0A9" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Wed, 1 Nov 2017 18:53:55 +0100 To: iasa20@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 17:54:01 -0000 --Apple-Mail=_94BFC48F-3D42-4348-B69F-47B89512A0A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you for the feedback we=E2=80=99ve received so far (incl. some = off-list). Much appreciated, and we are looking at it carefully. I would like to ask for more people to look at the document, and do so = even before the meeting, here on this list. I believe Alissa=E2=80=99s = plan is to come out of Singapore with a sense of the community on which = direction to pursue, and that can be best achieved if at least some of = the substantive discussion can happen before our meeting, and we can = better prepare for the questions and ideas people will have. The document is here: https://tools.ietf.org/html/draft-haberman-iasa20dt-recs-01 = Jari for the design team --Apple-Mail=_94BFC48F-3D42-4348-B69F-47B89512A0A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thank you for the feedback we=E2=80=99ve received so far = (incl. some off-list). Much appreciated, and we are looking at it = carefully.

I would = like to ask for more people to look at the document, and do so even = before the meeting, here on this list. I believe Alissa=E2=80=99s plan = is to come out of Singapore with a sense of the community on which = direction to pursue, and that can be best achieved if at least some of = the substantive discussion can happen before our meeting, and we can = better prepare for the questions and ideas people will have.

The document is = here:


Jari for the = design team

= --Apple-Mail=_94BFC48F-3D42-4348-B69F-47B89512A0A9-- From nobody Wed Nov 1 10:56:07 2017 Return-Path: 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 440CF13871A for ; Wed, 1 Nov 2017 10:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 V9cOYq7L4T7A for ; Wed, 1 Nov 2017 10:56:00 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id E565313F9A1 for ; Wed, 1 Nov 2017 10:55:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 76F522CFB1; Wed, 1 Nov 2017 19:55:58 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-FokGK_rmPx; Wed, 1 Nov 2017 19:55:57 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 696162CCC0; Wed, 1 Nov 2017 19:55:57 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <3f513064-44c8-2a8d-3e63-9c42c27b56cc@ericsson.com> Date: Wed, 1 Nov 2017 18:55:56 +0100 Cc: iasa20@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8817308B-DB09-4813-A071-5F1654F52916@piuha.net> References: <3f513064-44c8-2a8d-3e63-9c42c27b56cc@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Comments on draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 17:56:01 -0000 Thanks for your feedback, Gonzalo. > I realize discussions so far have been much more about how ISOC = supports > the IETF. Nevertheless, understanding that the IETF also supports = ISOC's > activities is important as well because those activities are very > relevant to the Internet community as a whole. Point taken.=20 > Lastly, as Ted mentioned, a good number of ISOC trustees are going to = be > attending the whole IETF meeting in Singapore. In addition, the whole > ISOC's board is going to be meeting also in Singapore right after the > IETF meeting. If you want to talk to any of us any any point, please = let > us know. The ISOC board has also decided to co-locate some of its > meetings with IETF meetings during 2018 as well (i.e., with IETF 101 = and > 103), so that the IETF community has access to the ISOC board during = the > IASA 2.0 process whenever it is needed. That=E2=80=99s important, and thank you for that. Jari From nobody Wed Nov 1 11:01:49 2017 Return-Path: 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 F383813F9EB for ; Wed, 1 Nov 2017 11:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 ErxdxS_b9a4Z for ; Wed, 1 Nov 2017 11:01:44 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 88E6213F9C5 for ; Wed, 1 Nov 2017 11:01:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D9DC52CFB1; Wed, 1 Nov 2017 20:01:43 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OscNzrlu47vp; Wed, 1 Nov 2017 20:01:43 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 4CF3F2CCC0; Wed, 1 Nov 2017 20:01:43 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Wed, 1 Nov 2017 19:01:42 +0100 Cc: iasa20@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Richard Barnes X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Review of draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 18:01:46 -0000 Thanks for your review and comments, Richard. Some further discussion = below: > > o Which direction the community would like to take the work in > > evolving IASA. >=20 > As above, I think the critical questions here are where the line = between > IETFAdminOrg and the remainder of ISOC should be drawn, and how it = should be > encoded. In light of those questions, I view the three options on = display here > as points along a trajectory or spectrum: Each represents an = increasingly hard > line, and will require correspondingly greater clarity about the roles = and > responsibilities of the entities on either side of that line. =20 Yes. Good point. > To be honest, I'm not totally sure where along the spectrum would be = optimal. > That said, a few thoughts: >=20 > * I don't see much point to IASA++. Given the degree to which this = exercise > is focused on increasing clarity and transparency, it seems worth = having a > clear organizational boundary and an entity that is clearly = accountable to > IETF. If you were to try to meet the clarity and transparency goals = while > keeping the activities within ISOC, you would end up effectively = creating a > subsidiary anyway, but without the benefit of the clear rules around = an > actual subsidiary. In other words, IASA++ is just an inferior = version of > the Subsidiary case. Ack. FWIW (and this is of course just my own opinion), I see it roughly = the same way. But I recognise that I might not see all the possibilities, so = lets keep discussing. > * I don't really see a lot of difference between the subsidiary and = independent > cases as long as ISOC remains a predominant funding source for the = IETF. Right. > On > the one hand, a subsidiary IETFAdminOrg will only ever be loosely = subsidiary > to ISOC, given that IETF is going to want to maintain a large degree = of > control/oversight over it. On the other hand, as long as IETF is = largely > reliant on ISOC for funding, ISOC will have a degree de facto = control > regardless of formal independence -- if they really don't like how = IETF is > being run, they can just pull the funding (or threaten to). Good point.=20 >=20 > * Likewise, in either the subsidiary or independent cases, there will = be a need > for an explicit contract / MoU with regard to funding. Yes. > * If there's going to be a new entity for IETFAdminOrg (vs. IASA++), = where it > falls on the subsidiary/independent spectrum will depend largely on = (1) how > its board is formed, and (2) what resources it shares with ISOC. So = it may > make more sense to focus more directly on these questions. That makes sense. Jari From nobody Wed Nov 1 11:10:16 2017 Return-Path: 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 34C3713FA03 for ; Wed, 1 Nov 2017 11:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 hYSxRZcudBF9 for ; Wed, 1 Nov 2017 11:10:12 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE67113FE54 for ; Wed, 1 Nov 2017 11:10:11 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id z19so3724179qtg.11 for ; Wed, 01 Nov 2017 11:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7jRpNKH8u9dFhO8KLLdgLesRJ1CFzgmIcdSZIZJE1fs=; b=n3oqtOTD5Q8O8v2Y5vUGpZxeemLMvB8uf2vl7B0sCbhnMfHOg9EBNId84rRj1gegsQ 0RtUf5Y228YP55KIvZXMBP1bbzddWVXt8bmpzp15SBDTln7jExPU28junClObBR7uSFn cZqwqcnf3RJWir+wfSqkGYsWiZGICmxm2EmCTRkillVr6AaLg1jlpReNw3olHY2dT1Iz fyPPkWi8jk5ZrZVDVLfumAPSMtni0aL4q8bAf920tWyRJ1XwobaZZw8eBqrbR9hV7u2c HNP4RdIgkVWN//in/pKACzwQXHcngWSDFw5cRVx7olwIgo6a1wdMig47fOjQLibzXJoE eSiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7jRpNKH8u9dFhO8KLLdgLesRJ1CFzgmIcdSZIZJE1fs=; b=ryxmKvD5JPsHlwufickhOM83CvmKkaLDwa7bhv/PEuUx40Ljske+WDYIX1SnDELyOE pzPcGApdpKYqRRYm2mFgnfmPj0jlfC0vijAa92bTORaEcyw3VZG2YeXRr10nPv8MK2oL KwsBmdvrWYe5ug+oHJnp9lnG0A5MUTTb9tefe1GA7ypLVfZzAozqOqgcxGAb8N2ImySb Qmk4POvB501uzFm2yTZYagrQjTJEZDRDy371nWkBcIB6f5TYwtCH0mFZvfP71+Ch7sDr aQ9yr0bzaNs1jtyoV6LGwmJiy1JK77apLn5xxCfMF0oq1PDFws4bTAfGLo+/mBXqKxyz Xl3Q== X-Gm-Message-State: AMCzsaUN8+fLceq8hUSRJlfuY23X4KA+8ocQxeWexkIvUmltINbQKkh0 W/b6kL1TassAo+q54Bc5zvnhEpdi2ENdqDcKOmQ= X-Google-Smtp-Source: ABhQp+QTbut8mCDeToOtDGjMtVJowPIOJ/JepU5R0SRZ5lFa9x20uR14fg0QBmDnJNfQRTrudOH/7n5qtOCx/oAlHMM= X-Received: by 10.200.35.173 with SMTP id q42mr1131978qtq.199.1509559810766; Wed, 01 Nov 2017 11:10:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.40.68 with HTTP; Wed, 1 Nov 2017 11:09:40 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Wed, 1 Nov 2017 11:09:40 -0700 Message-ID: To: Jari Arkko Cc: Richard Barnes , iasa20@ietf.org Content-Type: multipart/alternative; boundary="001a1142f08a49bcc7055cefc880" Archived-At: Subject: Re: [Iasa20] Review of draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 18:10:14 -0000 --001a1142f08a49bcc7055cefc880 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 1, 2017 at 11:01 AM, Jari Arkko wrote: > Thanks for your review and comments, Richard. Some further discussion > below: > > > To be honest, I'm not totally sure where along the spectrum would be > optimal. > > That said, a few thoughts: > > > > * I don't see much point to IASA++. Given the degree to which this > exercise > > is focused on increasing clarity and transparency, it seems worth > having a > > clear organizational boundary and an entity that is clearly > accountable to > > IETF. If you were to try to meet the clarity and transparency goals > while > > keeping the activities within ISOC, you would end up effectively > creating a > > subsidiary anyway, but without the benefit of the clear rules around an > > actual subsidiary. In other words, IASA++ is just an inferior version > of > > the Subsidiary case. > > Ack. FWIW (and this is of course just my own opinion), I see it roughly the > same way. But I recognise that I might not see all the possibilities, so > lets > keep discussing. > > I believe is fair to say, though, that setting up a subsidiary requires both an up-front cost and continuing costs that are larger than would be entailed by a re-org within ISOC. regards, Ted --001a1142f08a49bcc7055cefc880 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 1, 2017 at 11:01 AM, Jari Arkko <jari.arkk= o@piuha.net> wrote:
Thanks for your review and = comments, Richard. Some further discussion below:

> To be honest, I'm not totally sure where along the spectrum would = be optimal.
> That said, a few thoughts:
>
> * I don't see much point to IASA++.=C2=A0 Given the=C2=A0 degree t= o which this exercise
>=C2=A0 =C2=A0is focused on increasing clarity and transparency, it seem= s worth having a
>=C2=A0 =C2=A0clear organizational boundary and an entity that is clearl= y accountable to
>=C2=A0 =C2=A0IETF.=C2=A0 If you were to try to meet the clarity and tra= nsparency goals while
>=C2=A0 =C2=A0keeping the activities within ISOC, you would end up effec= tively creating a
>=C2=A0 =C2=A0subsidiary anyway, but without the benefit of the clear ru= les around an
>=C2=A0 =C2=A0actual subsidiary.=C2=A0 In other words, IASA++ is just an= inferior version of
>=C2=A0 =C2=A0the Subsidiary case.

Ack. FWIW (and this is of course just my own opinion), I see it roug= hly the
same way. But I recognise that I might not see all the possibilities, so le= ts
keep discussing.



I believe is fair to say, though, that setting up a subsidiary= requires both an up-front cost and continuing costs that are larger than w= ould be entailed by a re-org within ISOC.

regards,

Ted
--001a1142f08a49bcc7055cefc880-- From nobody Wed Nov 1 12:09:02 2017 Return-Path: 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 5C8A913F5E9 for ; Wed, 1 Nov 2017 12:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 JxPpLClRR12l for ; Wed, 1 Nov 2017 12:08:58 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 785E313FA4A for ; Wed, 1 Nov 2017 12:08:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 65A452CFB1; Wed, 1 Nov 2017 21:08:57 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWYQzh7Bz20j; Wed, 1 Nov 2017 21:08:56 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id C6D012CCC0; Wed, 1 Nov 2017 21:08:56 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Wed, 1 Nov 2017 20:08:56 +0100 Cc: Richard Barnes , iasa20@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <86351A17-A04C-4B83-BAF5-F9F196CA1368@piuha.net> References: To: Ted Hardie X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Review of draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 19:09:00 -0000 > I believe is fair to say, though, that setting up a subsidiary = requires both an up-front cost and continuing costs that are larger than = would be entailed by a re-org within ISOC. Yes. (And I=E2=80=99ve seen your comment about IASA++ potentially also been = seen as stronger integration with ISOC. That was what I was thinking of = when I said we need to keep discussing=E2=80=A6 I want to understand = that better. But will save that discussion to another email.) Jari From nobody Wed Nov 1 12:28:17 2017 Return-Path: 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 CA9A113FE77 for ; Wed, 1 Nov 2017 12:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 viteCvSEQ8JE for ; Wed, 1 Nov 2017 12:28:15 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D13BA13F58C for ; Wed, 1 Nov 2017 12:28:14 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id r68so6882911wmr.3 for ; Wed, 01 Nov 2017 12:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IHiaHgXSdtNt0oZ39je/3DcF+pWIWHnAkPpZhFkdpHU=; b=WrBBz5Z7i9VYU2bLtCecMkCUWkrlfPIt9e9yEqR3LoloDARrOe1wIZjT1jeAA73QF5 W+SXglbIIuJe1pdjcJToWfhsUQPHtenl04DwUJypHdJRqMhFZ6Mh7E3smxk/XNUU5M73 jIHvj+E72yUEj9q/7ZTFV0lS+QUEK/soawQIse/Wo2hNOSifBtIkbPzxWvPpd7tuA6jc LQN4lp58pPVYWMlewmNdolRuvsih8UqPX4IMYdJWlmopfXXQFDQygV9q+84gLrt2YBiH omhwbW0r76Wm9rwzKSnyHGLYRZj5+0NGtaTvxiWp6/u9qEviDecnGHMq3kwO2PgRERmg ezSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IHiaHgXSdtNt0oZ39je/3DcF+pWIWHnAkPpZhFkdpHU=; b=qrhqOrXFMqNOHzXNDGyCapXePR3i93tvoeNKNjTSyKSFYJHpiMPmPteOHdF/DiXp1K 2c/TC62RXjx974cnAgEIbjhvwV8k3pqTbbq8s42JmK43wBHubkbsin8rFi8bde/MastY OeBCj46Q8wfWfgtRgLxd/RcY2OJtrgdnfVkbL5mOsfGPAf2LOEUhP3ADKSRahKXWW46W DPy15Qk/mSiUO/0Y7Nj84nMsQ7Tci4gKyBCGJ9ooynguUrv5MQt+/MlJoF4UmclUVGHU tmSQL15WoTu3fW+G7onjhv4d3RjyirPXcrCeTDIkXPsSwXVqi2n8KVxcLk4v/1nfnm3y pSLQ== X-Gm-Message-State: AMCzsaUeXlhHT9TSfilM0K3vxsukYbitxgN5RcsMPHFoMas42a0Yh/AN TcBkiXRB5hkv1vl6kd5fdMQwHgzZ+VkgpucSpphPll4s X-Google-Smtp-Source: ABhQp+SiHTTUuMWAfchaqFlx/pZCtUIKqEjhnSmER/fl4lLjaVyJdJi9+vN2A+J3oWQWrVoWsQX5L6p2cWY4kuXP4T4= X-Received: by 10.28.156.67 with SMTP id f64mr976997wme.42.1509564492886; Wed, 01 Nov 2017 12:28:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Wed, 1 Nov 2017 12:28:12 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Wed, 1 Nov 2017 15:28:12 -0400 Message-ID: To: Ted Hardie Cc: Jari Arkko , iasa20@ietf.org Content-Type: multipart/alternative; boundary="001a114b32085d6f55055cf0df93" Archived-At: Subject: Re: [Iasa20] Review of draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 19:28:17 -0000 --001a114b32085d6f55055cf0df93 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 1, 2017 at 2:09 PM, Ted Hardie wrote: > On Wed, Nov 1, 2017 at 11:01 AM, Jari Arkko wrote: > >> Thanks for your review and comments, Richard. Some further discussion >> below: >> >> > To be honest, I'm not totally sure where along the spectrum would be >> optimal. >> > That said, a few thoughts: >> > >> > * I don't see much point to IASA++. Given the degree to which this >> exercise >> > is focused on increasing clarity and transparency, it seems worth >> having a >> > clear organizational boundary and an entity that is clearly >> accountable to >> > IETF. If you were to try to meet the clarity and transparency goals >> while >> > keeping the activities within ISOC, you would end up effectively >> creating a >> > subsidiary anyway, but without the benefit of the clear rules around >> an >> > actual subsidiary. In other words, IASA++ is just an inferior >> version of >> > the Subsidiary case. >> >> Ack. FWIW (and this is of course just my own opinion), I see it roughly >> the >> same way. But I recognise that I might not see all the possibilities, so >> lets >> keep discussing. >> >> > > I believe is fair to say, though, that setting up a subsidiary requires > both an up-front cost and continuing costs that are larger than would be > entailed by a re-org within ISOC. > Yes. The benefit that you buy with those costs is autonomy. If the organization resides within ISOC, then ISOC management can control it with whatever granularity they desire. If it is subsidiary, then the control is much more attenuated. So the operative question here is whether the autonomy is worth the costs. Personally, given the desire in this community for the IETFAdminOrg to be clearly accountable to the IETF community, and the level at which I would na=C3=AFvely expect the costs to come in (without having seen concrete estimates), my guess is that it will be worth it; thus the conclusion above= . --Richard > > regards, > > Ted > --001a114b32085d6f55055cf0df93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 1, 2017 at 2:09 PM, Ted Hardie <ted.ietf@gmail.com>= ; wrote:
On Wed, Nov 1, 2017 at 11:01 AM, Jari Arkko <= jari.arkko@piuha.= net> wrote:
Thanks for= your review and comments, Richard. Some further discussion below:

> To be honest, I'm not totally sure where along the spectrum would = be optimal.
> That said, a few thoughts:
>
> * I don't see much point to IASA++.=C2=A0 Given the=C2=A0 degree t= o which this exercise
>=C2=A0 =C2=A0is focused on increasing clarity and transparency, it seem= s worth having a
>=C2=A0 =C2=A0clear organizational boundary and an entity that is clearl= y accountable to
>=C2=A0 =C2=A0IETF.=C2=A0 If you were to try to meet the clarity and tra= nsparency goals while
>=C2=A0 =C2=A0keeping the activities within ISOC, you would end up effec= tively creating a
>=C2=A0 =C2=A0subsidiary anyway, but without the benefit of the clear ru= les around an
>=C2=A0 =C2=A0actual subsidiary.=C2=A0 In other words, IASA++ is just an= inferior version of
>=C2=A0 =C2=A0the Subsidiary case.

Ack. FWIW (and this is of course just my own= opinion), I see it roughly the
same way. But I recognise that I might not see all the possibilities, so le= ts
keep discussing.



I believe is fair to say, though, that setting up a subsidiary req= uires both an up-front cost and continuing costs that are larger than would= be entailed by a re-org within ISOC.

=
Yes.=C2=A0 The benefit that you buy with those costs is autonomy= .=C2=A0 If the organization resides within ISOC, then ISOC management can c= ontrol it with whatever granularity they desire.=C2=A0 If it is subsidiary,= then the control is much more attenuated.=C2=A0 So the operative question = here is whether the autonomy is worth the costs.

P= ersonally, given the desire in this community for the IETFAdminOrg to be cl= early accountable to the IETF community, and the level at which I would na= =C3=AFvely expect the costs to come in (without having seen concrete estima= tes), my guess is that it will be worth it; thus the conclusion above.
<= /div>

--Richard

=C2=A0

regards,

Ted

--001a114b32085d6f55055cf0df93-- From nobody Wed Nov 1 15:40:01 2017 Return-Path: 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 2CEAF13FF18 for ; Wed, 1 Nov 2017 15:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 ZkebUuFlcvv0 for ; Wed, 1 Nov 2017 15:39:55 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4E72113FF12 for ; Wed, 1 Nov 2017 15:39:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 987F42CFB1; Thu, 2 Nov 2017 00:39:53 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kabrQuMe3f0H; Thu, 2 Nov 2017 00:39:52 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 421F52CCC0; Thu, 2 Nov 2017 00:39:52 +0200 (EET) (envelope-from jari.arkko@piuha.net) From: Jari Arkko Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A9D2E32D-D0DE-4172-8210-CD82030962BA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 1 Nov 2017 23:39:51 +0100 In-Reply-To: Cc: iasa20@ietf.org To: Ted Hardie References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Thoughts on draft-haberman-iasa20dt-recs-01.txt X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 22:39:59 -0000 --Apple-Mail=_A9D2E32D-D0DE-4172-8210-CD82030962BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks much for this, Ted. > Reading through it, I was particularly struck by a much stronger = recognition that some of the issues we face are because of decline in = volunteer time as well as external support. It remains a bit hard to = understand the design team's perception of how these proposals will = influence those, but I attribute this to the design team hoping = community members will analyze this for themselves. Still, if the = design team has a consensus view, a somewhat stronger statement of it = would be welcome. Just speaking for myself, the issue with decline of volunteers for admin = tasks in particular has been growing more serious in my mind in the last = year. But as to how that (or external support) affects the different = options=E2=80=A6 that=E2=80=99s a good question. I don=E2=80=99t have an = answer immediately but we can think about that. > By my reading, IASA++ represents a very wide range possibilities, from = something close to "do nothing but be open about the issues" (publish = this doc and stop, in other words) to a restructuring of the activity = within ISOC that would be similar in scope to setting up a subsidiary. = It may be useful to mark out some explicit point along that spectrum, as = different community members' understandings of that activity may result = a false sense of shared understanding. Point taken. > I also note that the draft discusses the IETF's administrative = arrangements without quite saying explicitly that these include the IRTF = and IAB. It would be useful to make that clear. It is particularly = noteworthy on the IAB front because of two issues. First, the charter = of of the IAB (RFC 2850, Section 2) explicitly calls out that it has a = dual role as a committee of the IETF and an advisory body of the = Internet Society. Second, the IAB manages many liaison relationships = for the IETF community, but some of these are formally arrangements with = the Internet Society. The Category A liaisons to ISO managed by the IAB = are, for example, relationships between ISO and ISOC: = https://www.iso.org/organization/9418.html = . ISOC is also a sector = member of the ITU-T, and that is the source of some of our ability to = interact with the ITU. It is my perspective that moving to an entirely = separate organization would required that these be recreated (no doubt = with ISOC's support). It is not clear to me whether the creation of a = subsidiary would trigger the same requirement, but it seems less likely = or necessary in that case (as the formal relationship remaining with = ISOC could be part of the subsidiary agreement). Another good point. Taken. > The draft also discusses the potential relationship of new entities = with the IETF Trust. My personal take is that this is no longer simple, = because the IETF trust also holds the IANA IPR on behalf of a larger = community. I would recommend not trying to move it into another = organization, at least until that organization is well-established and = the impact of the change on its stability can be assessed. The = agreement of the wider community would also be required. Did you mean that IETF Trust should not get into the middle of the = reorganisation and be moved around? If so, I personally agree with you. = I actually think there are even structural issues that speak in favour = of keeping the Trust out of IETFAdminOrg permanently. The design team = document doesn=E2=80=99t say the Trust must be kept out of this, but = that=E2=80=99s at least partially because we wanted to produce analysis = and information and maybe stop short of trying to tell the IETF what to = do. But at least I have a personal opinion about the (non) role of Trust = here. > My next comment is on the delicate subject of money. Going through = this exercise is already costing us volunteer time, and many of the = changes proposed will result in staff time either on a one-off or a = continuing basis. Change for change's sake is expensive, in other = words, and we should generally justify it either in very clear community = needs or in substantial returns on the investment in change. = Transparency-related changes seem to me to fall in the community needs = category. Within the document I see three changes that seem to be = strongly focused on monetary returns on investment : >=20 > 1) Clear fund-raising responsibilities (discussed in Section 5.5) =20 > 2) Improve accounting of costs (discussed in section 6.3) > 3) Support a re-envisioned funding model (discussed in section 6.1)=20= All of that seems about right. > Some other proposed changes are not so clear. The inclusion of a = director of communications in the proposed staff, for example, might be = to support awareness of the organization for fund-raising purposes, to = support awareness and adoption of our standards, or to support awareness = of our work to encourage participation by new volunteers. Clarity on = how the work will support the IETF in the future would be a useful = touchstone in analyzing whether this is a change that is a must-have for = right now. Good question and a fair request. Although the specific case of director = of communications is IMHO more about clarifying a role (and an almost = full-time person) that in practice already exists today. > Lastly,in the interests of full transparency, I think the Internet = Society has been a consistent source of support and insight since we = made the previous transition, and I generally favor the approaches which = maintain a strong relationship between the IETF and ISOC. I agree that = the changes in activities on both sides necessitate a re-examination of = how that relationship works, and if the most appropriate change is to a = subsidiary structure, I am ready to support that. But I disagree with = Richard's analysis that IASA++ is an inferior form of the subsidiary = approach. IASA++ could imply a much stronger integration with ISOC than = we have previously seen, and that could go in a variety of ways. =20 >=20 > To give one example, ISOC could decide in the course of the IASA++ = re-organization to use a more-contractor heavy approach to some of its = other work and to manage the overall costs by using the same contractors = for IETF work and other Internet Society work. That approach (similar to = the "task requester" approach used in some government agencies) would be = a change to the way the Internet Society works that would make the IETF = work a more natural fit to ISOC's other working methods. Put another = way, IASA++ is really an Internet Society reorg, and assessing whether = or not it is the right choice depends heavily on the extent to which = ISOC is interested in a re-org of that scope, which would necessarily = affect its other activities if it is to be successful. Here I need more help to understand what you=E2=80=99re thinking. I=E2=80=99= ve been having trouble imagining the kinds of things we can improve in = IASA++. Your general point about the possibility of integration as = good/useful thing is taken. And I understand the more contractor heavy = organisational model. And I understand the benefits of integration and = synergy effects in general. What I=E2=80=99m having trouble is = understanding how they fit our case, and how they help solve the = problems about lack of clarity and clear lines of authority and other = things that we=E2=80=99ve found troublesome. But I=E2=80=99m very interested in understanding what useful things we = could do here, as at least I could have missed many opportunities here = and probably the same is true of the rest of the design team. Can you = help us, e.g., by sketching some things that we could do here? > I am happy to note that the ISOC Board is meeting in Singapore just = after the upcoming IETF, and I hope that clarity on that point can come = from them as well. Yes, indeed. Jari --Apple-Mail=_A9D2E32D-D0DE-4172-8210-CD82030962BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks much for this, Ted.

Reading through it, I was particularly struck by a much = stronger recognition that some of the issues we face are because of = decline in volunteer time as well as external support.  It remains = a bit hard to understand the design team's perception of how these = proposals will influence those, but I attribute this to the design team = hoping community members will analyze this for themselves.  Still, = if the design team has a consensus view, a somewhat stronger statement = of it would be welcome.

Just speaking for myself, the issue = with decline of volunteers for admin tasks in particular has been = growing more serious in my mind in the last year.

But as to how that (or external support) affects = the different options=E2=80=A6 that=E2=80=99s a good question. I don=E2=80= =99t have an answer immediately but we can think about that.

By my = reading, IASA++ represents a very wide range possibilities, from = something close to "do nothing but be open about the issues" (publish = this doc and stop, in other words) to a restructuring of the activity = within ISOC that would be similar in scope to setting up a = subsidiary.  It may be useful to mark out some explicit point along = that spectrum, as different community members' understandings of that = activity may result  a false sense of shared understanding.

Point taken.

I also note that the draft discusses the IETF's = administrative arrangements without quite saying explicitly that these = include the IRTF and IAB.  It would be useful to make that = clear.  It is particularly noteworthy on the IAB front because of = two issues.  First, the charter of of the IAB (RFC 2850, Section 2) = explicitly calls out that it has a dual role as a committee of the IETF = and an advisory body of the Internet Society.  Second, the IAB = manages many liaison relationships for the IETF community, but some of = these are formally arrangements with the Internet Society.  The = Category A liaisons to ISO managed by the IAB are, for example, = relationships between ISO and ISOC: https://www.iso.org/organization/9418.html .  ISOC = is also a sector member of the ITU-T, and that is the source of some of = our ability to interact with the ITU.  It is my perspective that = moving to an entirely separate organization would required that these be = recreated (no doubt with ISOC's support).  It is not clear to me = whether the creation of a subsidiary would trigger the same requirement, = but it seems less likely or necessary in that case (as the formal = relationship remaining with ISOC could be part of the subsidiary = agreement).
Another good point. Taken.

The draft also discusses the potential = relationship of new entities with the IETF Trust.  My personal take = is that this is no longer simple, because the IETF trust also holds the = IANA IPR on behalf of a larger community.  I would recommend not = trying to move it into another organization, at least until that = organization is well-established and the impact of the change on its = stability can be assessed.  The agreement of the wider community = would also be required.

Did you mean that IETF Trust should not get into the = middle of the reorganisation and be moved around? If so, I personally = agree with you. I actually think there are even structural issues that = speak in favour of keeping the Trust out of IETFAdminOrg permanently. = The design team document doesn=E2=80=99t say the Trust must be kept out = of this, but that=E2=80=99s at least partially because we wanted to = produce analysis and information and maybe stop short of trying to tell = the IETF what to do. But at least I have a personal opinion about the = (non) role of Trust here.

My next comment is on the = delicate subject of money.  Going through this exercise is already = costing us volunteer time, and many of the changes proposed will result = in staff time either on a one-off or a continuing basis.  Change = for change's sake is expensive, in other words, and we should generally = justify it either in very clear community needs or in substantial = returns on the investment in change.  Transparency-related changes = seem to me to fall in the community needs category.  Within the = document I see three changes that seem to be strongly focused on = monetary returns on investment :

1) = Clear fund-raising responsibilities (discussed in Section 5.5) 
2) Improve accounting of costs (discussed in section = 6.3)
3) Support a re-envisioned funding model = (discussed in section  6.1) 

All of that seems about right.

Some other proposed changes = are not so clear.  The inclusion of a director of communications in = the proposed staff, for example, might be to support awareness of the = organization for fund-raising purposes, to support awareness and = adoption of our standards, or to support awareness of our work to = encourage participation by new volunteers.  Clarity on how the work = will support the IETF in the future would be a useful touchstone in = analyzing whether this is a change that is a must-have for right now.
Good question and a fair request. Although the = specific case of director of communications is IMHO more about = clarifying a role (and an almost full-time person) that in practice = already exists today.

Lastly,in the interests of full transparency, I think the = Internet Society has been a consistent source of support and = insight  since we made the previous transition, and I generally = favor the approaches which maintain a strong relationship between the = IETF and ISOC.  I agree that the changes in activities on both = sides necessitate a re-examination of how that relationship works, and = if the most appropriate change is to a subsidiary structure, I am ready = to support that.  But I disagree with Richard's analysis that = IASA++ is an inferior form of the subsidiary approach.  IASA++ = could imply a much stronger integration with ISOC than we have = previously seen, and that could go in a variety of ways. 

To give one example, ISOC could decide in the = course of the IASA++ re-organization to use a more-contractor heavy = approach to some of its other work and to manage the overall costs by = using the same contractors for IETF work and other Internet Society = work. That approach (similar to the "task requester" approach used in = some government agencies) would be a change to the way the Internet = Society works that would make the IETF work a more natural fit to ISOC's = other working methods.   Put another way, IASA++ is really an = Internet Society reorg, and assessing whether or not it is the right = choice depends heavily on the extent to which ISOC is interested in a = re-org of that scope, which would necessarily affect its other = activities if it is to be successful. =

Here I need more help to understand what you=E2=80=99= re thinking. I=E2=80=99ve been having trouble imagining the kinds of = things we can improve in IASA++. Your general point about the = possibility of integration as good/useful thing is taken. And I = understand the more contractor heavy organisational model. And I = understand the benefits of integration and synergy effects in general. = What I=E2=80=99m having trouble is understanding how they fit our case, = and how they help solve the problems about lack of clarity and clear = lines of authority and other things that we=E2=80=99ve found = troublesome.

But I=E2=80=99m very = interested in understanding what useful things we could do here, as at = least I could have missed many opportunities here and probably the same = is true of the rest of the design team. Can you help us, e.g., by = sketching some things that we could do here?

I am happy to note that the = ISOC Board is meeting in Singapore just after the upcoming IETF, and I = hope that clarity on that point can come from them as well.
Yes, indeed.

Jari

= --Apple-Mail=_A9D2E32D-D0DE-4172-8210-CD82030962BA-- From nobody Wed Nov 1 19:11:57 2017 Return-Path: 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 3698313F704 for ; Wed, 1 Nov 2017 19:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FYJMyAVtLxVU for ; Wed, 1 Nov 2017 19:11:54 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C1313942F for ; Wed, 1 Nov 2017 19:11:54 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id z195so3493666ywz.6 for ; Wed, 01 Nov 2017 19:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dhwSV4qYm8AO55TPx1BcqmrlVOUTdVRRVJKummpOz70=; b=FxXj/TZt1wRvYbwvrWxCluhrIkZ0jYhne/4sb84cQ8jJntx3BVYuur1OguyaQMv8o2 +QUkT4yfe5l5azfLvp5bdf6zSBFJxcaHzqeDbqFFbexUOya0uFNh6Uv6hg1cue7XGNeg S9O285lDfxiUT9Dz/CwaTJYsCHn8crCPV39IMcXd5f7DHXgfgREVXOhw3YOowhT2AIqE hnH83XV3pZ3ooVthwL8yib+WTv7+inaK6JwusZRnS/4iL+H7zdv0RK207Vx9HEgAhIVl lNaDsqSTEI6t2oD3XbUO+y4GgvrMnip09wdoi72dU8vHOuIEOSpl3jQrgr5RrFivTtL2 b5uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dhwSV4qYm8AO55TPx1BcqmrlVOUTdVRRVJKummpOz70=; b=X69pOFOpTbjpg0lMNV1fuB0BisWP+Z5/m4hbxA7bB94Ax66lYIZrb0PrqN80DmelGR JGKiRfXYLqhrbFAvhN9Tczs+odhJ8F2tsxOE2U4DoeVqv6MlKsFoBQqeNeskfaiJVEt5 ZeaZSJQ83VAmn7xDddvv7dLsYmWyXeG3542IlBqQZcqQrutcXhhMRaJAYuLF0KQOd6Sc DGODHPXmJ60DXGAB8NbiXm2jP4EOQ3Be/YPKGMLgATqowrUF6If31wQKTqoS2n/eym57 GMjjk27yMvFjGBB9MzmVecDZvGyK+eGUYJUYwJcMlfoxqGBneCoYvQCO3kB1KjCFhSTk eLtg== X-Gm-Message-State: AMCzsaWOgZHych9eIjB0HTztPUoOUkANBMSXip8XTgwL7eF1z7lMdeYA brv72B02rgPSKRK3pXjmsLbeWggv7emvPSGzyVc= X-Google-Smtp-Source: ABhQp+SD82noELIqtApHoEyoDlYTTQcKoTICh8V23XVkFV4JrXwQvNfKM0WJllxqRL9WlWV9/EMZv0SBIz/O4bt+6L8= X-Received: by 10.13.214.142 with SMTP id y136mr1263927ywd.240.1509588713272; Wed, 01 Nov 2017 19:11:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.164.79 with HTTP; Wed, 1 Nov 2017 19:11:22 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Wed, 1 Nov 2017 19:11:22 -0700 Message-ID: To: Jari Arkko Cc: iasa20@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0762e60300e9055cf6832a" Archived-At: Subject: Re: [Iasa20] Thoughts on draft-haberman-iasa20dt-recs-01.txt X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 02:11:56 -0000 --94eb2c0762e60300e9055cf6832a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 1, 2017 at 3:39 PM, Jari Arkko wrote: > > > The draft also discusses the potential relationship of new entities with > the IETF Trust. My personal take is that this is no longer simple, becau= se > the IETF trust also holds the IANA IPR on behalf of a larger community. = I > would recommend not trying to move it into another organization, at least > until that organization is well-established and the impact of the change = on > its stability can be assessed. The agreement of the wider community woul= d > also be required. > > > Did you mean that IETF Trust should not get into the middle of the > reorganisation and be moved around? > Yes, that's what I meant. If so, I personally agree with you. I actually think there are even > structural issues that speak in favour of keeping the Trust out of > IETFAdminOrg permanently. The design team document doesn=E2=80=99t say th= e Trust > must be kept out of this, but that=E2=80=99s at least partially because w= e wanted > to produce analysis and information and maybe stop short of trying to tel= l > the IETF what to do. But at least I have a personal opinion about the (no= n) > role of Trust here. > > Lastly,in the interests of full transparency, I think the Internet Societ= y > has been a consistent source of support and insight since we made the > previous transition, and I generally favor the approaches which maintain = a > strong relationship between the IETF and ISOC. I agree that the changes = in > activities on both sides necessitate a re-examination of how that > relationship works, and if the most appropriate change is to a subsidiary > structure, I am ready to support that. But I disagree with Richard's > analysis that IASA++ is an inferior form of the subsidiary approach. > IASA++ could imply a much stronger integration with ISOC than we have > previously seen, and that could go in a variety of ways. > > To give one example, ISOC could decide in the course of the IASA++ > re-organization to use a more-contractor heavy approach to some of its > other work and to manage the overall costs by using the same contractors > for IETF work and other Internet Society work. That approach (similar to > the "task requester" approach used in some government agencies) would be = a > change to the way the Internet Society works that would make the IETF wor= k > a more natural fit to ISOC's other working methods. Put another way, > IASA++ is really an Internet Society reorg, and assessing whether or not = it > is the right choice depends heavily on the extent to which ISOC is > interested in a re-org of that scope, which would necessarily affect its > other activities if it is to be successful. > > > Here I need more help to understand what you=E2=80=99re thinking. I=E2=80= =99ve been having > trouble imagining the kinds of things we can improve in IASA++. Your > general point about the possibility of integration as good/useful thing i= s > taken. And I understand the more contractor heavy organisational model. A= nd > I understand the benefits of integration and synergy effects in general. > What I=E2=80=99m having trouble is understanding how they fit our case, a= nd how > they help solve the problems about lack of clarity and clear lines of > authority and other things that we=E2=80=99ve found troublesome. > > But I=E2=80=99m very interested in understanding what useful things we co= uld do > here, as at least I could have missed many opportunities here and probabl= y > the same is true of the rest of the design team. Can you help us, e.g., b= y > sketching some things that we could do here? > > A recent example is the shifting of some accounting tasks related to the IAOC from ISOC to a contract with AMS (actually an amendment to the secretariat contract). In an IASA++ world with a tighter integration, ISOC could have considered or implemented a move of its other accounting requirements to an outside contractor, which the IETF would have then shared. As I said in my previous note, this approach very much depends on the appetite of ISOC to have a reorg of facilities unrelated to the IETF, so they were in greater alignment. That's a matter for the Trustees and staff= . I hope that example helps clarify that avenue of discussion, regards, Ted --94eb2c0762e60300e9055cf6832a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 1, 2017 at 3:39 PM, Jari Arkko <jari.arkko= @piuha.net> wrote:
<snip>
The draft also discusses the = potential relationship of new entities with the IETF Trust.=C2=A0 My person= al take is that this is no longer simple, because the IETF trust also holds= the IANA IPR on behalf of a larger community.=C2=A0 I would recommend not = trying to move it into another organization, at least until that organizati= on is well-established and the impact of the change on its stability can be= assessed.=C2=A0 The agreement of the wider community would also be require= d.

Did you mean that IETF Trust should not get into the middle of the reorga= nisation and be moved around?
Yes, that's what I meant.

If so= , I personally agree with you. I actually think there are even structural i= ssues that speak in favour of keeping the Trust out of IETFAdminOrg permane= ntly. The design team document doesn=E2=80=99t say the Trust must be kept o= ut of this, but that=E2=80=99s at least partially because we wanted to prod= uce analysis and information and maybe stop short of trying to tell the IET= F what to do. But at least I have a personal opinion about the (non) role o= f Trust here.

Lastly,in the inte= rests of full transparency, I think the Internet Society has been a consist= ent source of support and insight=C2=A0 since we made the previous transiti= on, and I generally favor the approaches which maintain a strong relationsh= ip between the IETF and ISOC.=C2=A0 I agree that the changes in activities = on both sides necessitate a re-examination of how that relationship works, = and if the most appropriate change is to a subsidiary structure, I am ready= to support that.=C2=A0 But I disagree with Richard's analysis that IAS= A++ is an inferior form of the subsidiary approach.=C2=A0 IASA++ could impl= y a much stronger integration with ISOC than we have previously seen, and t= hat could go in a variety of ways.=C2=A0

To give one example, ISOC = could decide in the course of the IASA++ re-organization to use a more-cont= ractor heavy approach to some of its other work and to manage the overall c= osts by using the same contractors for IETF work and other Internet Society= work. That approach (similar to the "task requester" approach us= ed in some government agencies) would be a change to the way the Internet S= ociety works that would make the IETF work a more natural fit to ISOC's= other working methods.=C2=A0=C2=A0 Put another way, IASA++ is really an In= ternet Society reorg, and assessing whether or not it is the right choice d= epends heavily on the extent to which ISOC is interested in a re-org of tha= t scope, which would necessarily affect its other activities if it is to be= successful.
Here I need more help to understand what you=E2=80=99re= thinking. I=E2=80=99ve been having trouble imagining the kinds of things w= e can improve in IASA++. Your general point about the possibility of integr= ation as good/useful thing is taken. And I understand the more contractor h= eavy organisational model. And I understand the benefits of integration and= synergy effects in general. What I=E2=80=99m having trouble is understandi= ng how they fit our case, and how they help solve the problems about lack o= f clarity and clear lines of authority and other things that we=E2=80=99ve = found troublesome.

But I=E2=80=99m very interested= in understanding what useful things we could do here, as at least I could = have missed many opportunities here and probably the same is true of the re= st of the design team. Can you help us, e.g., by sketching some things that= we could do here?


A recent example is the shifting of some accounting = tasks related to the IAOC from ISOC to a contract with AMS (actually an ame= ndment to the secretariat contract).=C2=A0 In an IASA++ world with a tighte= r integration, ISOC could have considered or implemented a move of its othe= r accounting requirements to an outside contractor, which the IETF would ha= ve then shared.

As I said in my previous note, thi= s approach very much depends on the appetite of ISOC to have a reorg of fac= ilities unrelated to the IETF, so they were in greater alignment.=C2=A0 Tha= t's a matter for the Trustees and staff.

I hop= e that example helps clarify that avenue of discussion,

regards,

Ted
=C2=A0


--94eb2c0762e60300e9055cf6832a-- From nobody Fri Nov 3 05:25:21 2017 Return-Path: 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 9A7A613FDB0 for ; Fri, 3 Nov 2017 05:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 gfJGRe_Y0BlS for ; Fri, 3 Nov 2017 05:25:16 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0059.outbound.protection.outlook.com [104.47.42.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A5313FDB7 for ; Fri, 3 Nov 2017 05:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OM2j1F96gVTrEIrT0d0p8i8nB+3qYpGy5XzMdsaI40Y=; b=fc78UlobrYe9drP5w+5HMJfbOe+TQV7M2xoukxzsqS86ekEJqw/Fi+wRaAvrDZg7GLy+YeMzvdUb1mjPIMNtl47tmpge3pAdfbxZMomu0Zr6TqsCxwiKa9VFJlte0xmyo4tZsZdjfMWBRM9cu4rZKBVJnkVB2/YqQG12i2Fnw4c= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ford@isoc.org; Received: from [IPv6:2001:8b0:dcb:7d85:4d23:9b49:1b32:30e5] (2001:8b0:dcb:7d85:4d23:9b49:1b32:30e5) by CY1PR06MB2219.namprd06.prod.outlook.com (10.166.193.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Fri, 3 Nov 2017 12:25:13 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Matthew Ford In-Reply-To: Date: Fri, 3 Nov 2017 12:25:01 +0000 Cc: iasa20@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> References: To: Jari Arkko X-Mailer: Apple Mail (2.3445.4.7) X-Originating-IP: [2001:8b0:dcb:7d85:4d23:9b49:1b32:30e5] X-ClientProxiedBy: LO2P265CA0061.GBRP265.PROD.OUTLOOK.COM (10.166.104.153) To CY1PR06MB2219.namprd06.prod.outlook.com (10.166.193.154) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6f434a03-7d0d-45fa-8053-08d522b5efbd X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:CY1PR06MB2219; X-Microsoft-Exchange-Diagnostics: 1; CY1PR06MB2219; 3:4YfmFftdas+D/ayIWqXlykV3rFHrCz471hD/fU+SAh572KQX3Gwy8YKJ3bkCfd2JE4Xd1HsbXx+zT76zjxv07ljtRdkUR1RJfNXtHx54Fq85zgFr9yoc7TwvK6wxC8P1N6FuRr2ubfrRNeqdvS9inPo7Lpg4Zt0OnTtfcBRd1c//Q0diw3Ys4LRbF9eZeyjILyWReNT8LG8bmD6bGjnu9spn/CtmyFprVeRwcQOdf6Yyb8ZTVWMrta7tctS0kjPC; 25:WGrHy4QXBV8cpTD5GCPZT79MJZdrYmW4DI6gcBEO4ZWI1XPjGcSLxQqKiNiy7q8q3hHZ1jKENOaeRzmA7aUwCkeeyakyJhmg0y/JKU26jAQrVAaLZ499kH7/WUgj5PfckxAU/p/OAp1FXa57NBAUKpYhyJoO824128S4BXlQ3zZW4cye9J5YDM80yOH4O7GLJR63X7Y1vfIrWwu96+WQwhVLE0gdEoLsCobMVFWfyYiUVtuIr5JPx4sdcH/UdAQlu2AAtQ5Re6Kdkm78Z/iQlil5Qt2BCqnJZnvrctAt4IsGRiQw59ZFIzIxdMZKtU3YxsbOFvXpiDAERMLj6Xfu4w==; 31:mrzD46NGpT2USTXEXzD7pld/MHG+ml/YFFvjSZO79tJlpOt/F3XzqY1vZRYrvd5DiU1JX6RnIorEjIRWoKnnPXelUQozhiMan2IPienCYqOBmIgFmsskiOcc/2o3L3W79NznmN1s0ssU/g1hMxvWMHR4Ys7oKpD2Cuuuuu3KHt0ZmDECVE0UKOfNMT4bvrIdrHOdS+cr+fBWrkh6J++hzg2aYbB522cu7zuVGgmBook= X-MS-TrafficTypeDiagnostic: CY1PR06MB2219: X-LD-Processed: 89f84dfb-7285-4810-bc4d-8b9b5794554f,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; CY1PR06MB2219; 20:z/VFf58DTHrbkPHAWMLtixAhIdoGjxklyDe2grDEWGZnpAbJiV39sLmZsCXgewNpwukbPCLYrcvwMJVgBTTeJVyfVOfIm+/bbIVKpQxJehkyImVV4Fxuh0KuA8iapVM2EcQ8akt+8tU4lCjpzH/1/qz3CNk4dGY8gkJNy7d9HIjJkGui1pEqIMSI1zVitQuosY5aVq7XsuYre+Nv9miv2ihoGFf9o0VZtwvmIHIutkN63kXdji1kcUawu4IaHAakQeJzk8ksu3ges8VJ01Xhd1440ZuCMwHhVXQ2ZoXvoRL2edCuO1NPH/I0Jo0VobXNLFNh8+5VL0SFRID84VuFHqNmVyZ6YxRGNA1CcisuyxE5mHglVtYXV506meAwyojtbqzm2yK2BuHvpgNgZCifQ37Dt81fOzz7+3eqXUWUyiSDDp6R31XSAiHoCcj0cy5ac/NeADytimTiYYn5y6o4slKAONVifHoCFVSpLMg4X7ffoZyVdmWddtQUEfpNFEWi; 4:3T/v8hvQ+ZU1o+DD8vciU3mq+fEaCVlRkKsdXg3jIdH4JAGK5JN25Y3euy/hrW5ymsUjz2vRS/TtsKJb3W71Uyyd2DhYdnnUcd6WPbf3Bl112iEt5QuoRxoJ5te5xWFbgQFW6MEOS+YOA0uaTD1+JGlcdAyhn1yG9gEs6CEyrn6e8O37XoeQb2MjPQ2f1f7IDlKOczgSkyDhif+grft5Us44kvXOCVHZm3Scp2h191Fb3/B6QvMPh0bblh8sHkA83LpFQTGMXmbFV6fK/3adTiLebgDaMKYsRjPku5c6+Qy1IHbsNwE/uThxZ0wI/6ghOjJ0X3sjCI4ZG9PV5EOkEFr8m7uk0s1wvfN/5LQ1zXtg/FKkswGAqwqI0akTnTmpGY1bZh845KfDNfhayHK387OHelvma6cyatmJkRRhVYI= X-Exchange-Antispam-Report-Test: UriScan:(35073007944872)(5213294742642)(211171220733660)(231250463719595); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231021)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR06MB2219; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR06MB2219; X-Forefront-PRVS: 0480A51D4A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(346002)(39830400002)(376002)(127404002)(24454002)(189002)(199003)(8676002)(101416001)(305945005)(81166006)(7736002)(50226002)(2906002)(6486002)(53936002)(6246003)(6306002)(68736007)(229853002)(6116002)(33656002)(189998001)(50986999)(345774005)(76176999)(8746002)(81156014)(1706002)(82746002)(53546010)(105586002)(106356001)(8936002)(83716003)(316002)(6916009)(2950100002)(6666003)(25786009)(966005)(478600001)(36756003)(23676003)(47776003)(57306001)(50466002)(97736004)(5660300001)(86362001)(4326008)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR06MB2219; H:[IPv6:2001:8b0:dcb:7d85:4d23:9b49:1b32:30e5]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjA2TUIyMjE5OzIzOitEeVpHWE5NUS9yZjcwU28yUlNOVkxOa3FN?= =?utf-8?B?UzgzdzJoNnBLWndSSkkxWFNRQ0hTMWt1UkY0eHA2WFlxMkhxUEdQMEJweGh4?= =?utf-8?B?eXVQYXQxUVdrVzRKQ2Q5Z2xsSVNzRHlzY3BCMWEvQU80azNWa2RKd1h1NUdY?= =?utf-8?B?azN3SUtISXdEL1FCK1FtbFp1VGNUUXJuVUt0bEpwREVtY3lkdnd1dFU3d3FE?= =?utf-8?B?WGdCd3dFREJiNkwzd09FNkRrTFd3bVRvdXBkZ3dEd3ZFSXViU0ZESkN5d0pr?= =?utf-8?B?c0s0Q0dxSXNjNlgzR2pncERJYXNBdnkzWG5RWlhzVEZuM2Vtc3FydTFZLzVS?= =?utf-8?B?RzJXaEIvZm8vWnJUUWQ5WVJmTnQ0NC9QeW45RE9oZlVZRkh5SVBrdm5xUkVr?= =?utf-8?B?bTVHTndwZlliRUVKaGJYRjJ5ZUFJck5zZ2YxZ2lUelpiZ29DZHpCRkhrODVh?= =?utf-8?B?c21WS05VSXJsY3JMajdKZS9OUWk3TTAwN1M0MnN4SDNMcmZzbmtFYzBRTHpi?= =?utf-8?B?TnVaY01OWFFJa3I4YW04U25Sa1Flams3aHNzYzZsOWFrMSt3TVlsOVo1MmtB?= =?utf-8?B?SmJTcXlRUzVNdStJY1hOK2lySXRlcHFpWHRJdEovUnFMQVc3UFBiYUxSNHkx?= =?utf-8?B?VUtXZWpsbEZmR2trM2dpbjNpcEdycW9qRVRHS05RV1N4VFByZWViOEdKWWxy?= =?utf-8?B?dThnQkdnZGd2bmE1aGg1RTZNNFc0NUdNUE1vSEhTWDFGRjFaOEZkVGprQ1Rt?= =?utf-8?B?cFVQZ204TlFGQkJ2V2MzdGdqanp2VndIcHJ5TThxdG1DNitRd1VzdnVOcWdR?= =?utf-8?B?TFBNcFJsZ0NZOE04RTEzQVlGN2UvWkE3U05YUUNlQ05MQ2RaekVmenV4S1Br?= =?utf-8?B?Mm1JaTMrOGxqVlhHelJBN0lIdkdNdEJLZlVndzlZSStVcnVPdWlORWhDVm9G?= =?utf-8?B?UFNNVFpUOE8zNUw1VlZaMjhOUTVSUENHUzFvdVJuWDA4V1FVSGhZSUp6TC9S?= =?utf-8?B?eHJ2dVlsdDVJNHJ6N010bUZaYmdxQkd0YzgrczhSc0NPcXVXWUlOdU1qSWw5?= =?utf-8?B?ZlBveHBvVk1tdlN4Vmc0SWh6dVNvdThBRlZBQUxhZVl3UC9iVm1RNUlCMjFi?= =?utf-8?B?QXJscGpIMzlqVXFtVlVqWEFMeFpCcm5lTE96OVowZWFkNytraFdIMHpkUWJu?= =?utf-8?B?d3BlZHMxRjc0MklLTkxGSURlZ2I0Nmg3cWQyRGlNU2RLUGd5TnhoamdkNXQ5?= =?utf-8?B?MlJYYTlWelloaE5ZMWRmM0MrUmVSWXQzaGlGbW1lbmJxYlE3Z3Izam9SWWl3?= =?utf-8?B?K25aMGRyOGtjN0hUQXQrbTVtTU8zSUZwK2hPVEh4bHRITnpjc3Y0Y1dKS1d4?= =?utf-8?B?TXd5OGtUTWJ3WHZCMlY5dHQxV3RKQ2x0SkdwQnRPNHFKQWNqdjRIVUR5Tklu?= =?utf-8?B?NXVPRm5GTkhSaFREUVFJbFBPMW9PU0FzRUVmUldjWWUyM3MzOFE4THEwU1Vu?= =?utf-8?B?QVBhclR4Q1IyVFFSUGtzOHdNV0llOXJteGg0K0lreU5jNFZBVXFjTGowY09R?= =?utf-8?B?VU43RWpPZkQwTllqM0dxaSttNVg4c1pHbWhNYjlxUjd4VGpVYXZwbTZQSlVx?= =?utf-8?B?aTNqbjRuS0tKRDA2bmNDbmlRcm12U2daZHJvUjJRTzdtd21YcHZETjBuUXFX?= =?utf-8?B?ZUt3Z1hsQmFVV25KSk5kM0grOEJ6Nm1qcTFxUGRGWFFLZzIrV0JkdU92aG5i?= =?utf-8?Q?cEAORqbJjthhfeL2+Z3xCxcNYJfITnM96ezzM=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR06MB2219; 6:4kEErh3yIKEHQOFy2uXHbiPyt7BTfrFPuLmN7dDJf8GhY0KhvdI7ILGMxf20nZEUZvh5lA13UGV7TwYxNUh8wBZXeMNKW6GPqoiW+6ObLnDGvTqLj3li+1ueKwsDqqswLo4Q9r1sBJ2FQ3O2qDJwdgUJvRKBgtMmjPM9loyEuiGksa8aVdZy/Szf2793V0bfWa+SxVH63UKn4CoDRIlIbhWBF8FlBmN73TF0USArXDTLWXdZ0ezuO3rfY2eUZCeHJKY9V/k5Y78F7DdEBPiDV5gudhQHvSlzh/7dA6EeIWX0ENS9OOJagOQQVJ9bMH+LYXpPtekwuR1tfrLu8cK0oRCRCS1KeV8OLnWA4xHG60E=; 5:BRVrWjh3KS+1By/3Rkbq5M12x75tqO9YPCeFVcJwtI03MnWccat8p2JBoSDrEVj4PX8YZkwo5AOzDnPIldXb27cq7ZdoqT0auBJGr0r/INqdMM7dagnBrzfiRJ+9Ji1FVF8XvwnAK1U1yNK6buunpT3WFnBFtJ5MrOPcdMr06rQ=; 24:wpt0D5vSrC6V6Pda3lKSf+4cTTyB1gh1QoVgbrfV9j0R+bJ1VKG04qNz2zu8d2k5t+JOytl0MkeAiWXiW/Mpnsv2ATj/0boh5WCSw3X+nu8=; 7:fTg5gFyQ0fMKprJplgDMf0U+pwkUtmGBGNYa0TY6CD+VP+B5Kcb0bM6QzuAlrD/cfqLSn+T7asuhd9kCGd4lpRIRjaIn6U9rswCfWAeIVahEIs0P0CBRRt0UYDTik0o/dkT4HXW3vfLvgqG3T+vxWmfB5BsQ0+VMx2Qe0BafnqeDwuD7f/TMy08g43aNlXWH0DldgRmmvGav4buxHR6F6swWxxmKLJ7XEBrWuGuoRXz+HzYLe2VB9XrL0rG6do5P SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2017 12:25:13.7516 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6f434a03-7d0d-45fa-8053-08d522b5efbd X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR06MB2219 Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 12:25:20 -0000 Hi Jari, Thanks to you and the rest of the design team for this document - it is = clear that a lot of work and thought has gone into it. I offer some = personal comments (and identify a few editorial nits) below. These are = strictly my personal reflections as an IETF participant. To the questions set out at the beginning: o If the set of options outlined in this draft covers the options that should be looked at. MDF: Yes. o If the analysis of the implications of the options is correct. MDF: Broadly yes, although see my comments below. o Which direction the community would like to take the work in evolving IASA. MDF: My view is that the subsidiary option provides the means to address = the identified issues without incurring the unnecessary additional = challenge and expense of the independent org option.=20 IETFAdminOrg will be required to operated in a transparent fashion MDF: Nit - s/operated/operate o Improve the IETF's Technical Environment: Undertake changes to better enable technical contributors to focus more on that technical work and less on administrative work or support activities. This could for example mean directing more financial resources towards the creation of new or improvement of existing tools, which might be produced by contractors rather than solely by volunteers. As a result, volunteers could instead focus on developing the standards themselves. Thus, if the core competency of IETF attendees and their reason for participating in the IETF is to develop standards, then create an environment where they can focus exclusively on that activity and delegate to contractors, staff, or other resources the responsibility for creating and maintaining tools and processes to support this activity. MDF: This makes me uneasy. For this to work well, the responsiveness of = contractors/staff/other resources to the community is key. To date the = community has done an impressive job of building the tools it wants for = itself. The people who build those tools know what the community thinks = about them and hears about ways they can be improved and extended = because they are part of the community. I=E2=80=99m worried we get to = the point where IETFAdminOrg buys off-the-shelf solutions to solve a = management problem at the expense of the fine-grained needs of the = community. o Clearly Define the IETF-ISOC Relationship: Define the roles of IETF and ISOC in a way that helps the above structure be as clear as possible, in terms of who does what, how are things accounted for, and who is in charge of adjustments and control (e.g., staff resources). This also includes consideration of a new funding model that takes into account the historical responsibility for the IETF that ISOC has had since its inception. MDF: To the extent that the relationship between IETF and ISOC is of = ongoing importance then I think this will need care. The two = organisations benefit most from collaboration rather than = rule-following. I agree that things may have gotten to the point where = more clarity is required, but I=E2=80=99m just cautioning that providing = clarity doesn=E2=80=99t necessarily come without potential downsides = too. Continuing to allow for flexibility and creativity in how the two = organisations work together is important. o Clarify Overall Roles and Responsibilities: Ensure that all staff, contractor, and volunteer roles are clearly documented. This necessarily includes documenting how each of these parties may interact or interface with one another in order to conduct and support the business of the IETF. This also includes documenting key work processes, decision-making processes and authority (such as pertaining to meeting venue selection), etc. A key objective is to minimize ambiguity and uncertainty so that it is clear who is responsible for what and who has the power to make certain decisions. MDF: I agree that such documentation and clarity is needed. I think we = should strive for it to be as lightweight as possible - it shouldn=E2=80=99= t be hard for people in these roles to know what the right thing to do = is without referring to lengthy business process documentation. o Re-Define the Role of the IETF Community in Relation to Administrative Activities: As the roles and responsibilities for support staff and volunteer roles are clarified more precisely, the role of the IETF community in relation to those staff and volunteer roles must be better defined. This should acknowledge the limited time and availability of IETF volunteers, better defining expectations around oversight of and involvement in strategic, operational, and execution tasks within the administrative efforts. The new design needs to ensure that volunteers are not overloaded in such things as low level operational decisions, which can be delegated to and handled by staff, and can instead focus on strategic changes, critical decisions, and so on. In particular, this should focus on clearly documenting the lines between responsibility, representation, authority, and oversight. MDF: There is a tension between the primacy (as I see it) of the IETF = Community in its broadest sense, and the lack of interest in or time for = administrative work. The risk of capture by the AdminOrg is very real I = think. While delegation is clearly necessary, some things can=E2=80=99t = be delegated. Luckily we are blessed with a community that is pretty = vocal about things it doesn=E2=80=99t like :-) o Define Improved Transparency Requirements: The general level of operational transparency and information-sharing between IETF administrative staff and groups to the IETF community must be kept at an acceptable level, and improved where it makes sense in the future. This includes ensuring the timeliness of sharing of information and decisions, as well as seeking comment on prospective decisions. At the same time, we need to reset expectations around delegated authority so that once staff or an administrative support organization has been delegated certain authority it is clear that they are empowered to proceed in a particular area, so as to improve organizational efficiency, reduce friction, and improve the pace of work and decision-making. However, it is clear that enabling a group or staff to act within their delegated authority depends upon a clearer definition of roles and responsibilities, on improved transparency, on improved communications, and on trust (which is built upon all of those things over time). MDF: Yes! Strongly agreed. 5.1.3. Independent Organization In this option, a new non-profit organization (IETFAdminorg) is created independent from ISOC as the new legal home of the IETF. IETFAdminOrg would have its own bank account, by-laws, charter, board, staff, and corporate identity. The administrative staff for IETFAdminOrg could be kept lean and would likely rely on contractors for the bulk of administrative tasks. Minimally, the IETFAdminOrg staff would be responsible for administration, development/ fundraising, communications, and personnel management. In the independent organization model, IETFAdminOrg's continued existence would not depend on the ISOC organization's choices about its future. MDF: Except that it would, for the reasons you articulate below. To be = more constructive, given the constraints below, how would the = independent org option differ in practice from subsidiary option? Would = it be an explicit goal of an independent org to develop fundraising to = the point where ISOC support was not required? However, IETFAdminOrg would still depend on the ISOC's support, for two reasons: o ISOC's role in supporting the IETF, and o As a practical matter, IETFAdminOrg is not financially viable without ISOC's support. In order to establish this model, IETFAdminOrg and ISOC would need an explicit agreement that outlined expected levels of financial support going forward, both in terms of founding endowments and in terms of ongoing support. These agreements might also cover IETFAdminOrg's obligations to ISOC, such as the level of reporting from IETFAdminOrg to ISOC, and the expected structure of any liaisons. MDF: Given these constraints, I don=E2=80=99t see the practical = difference between this option and subsidiary. As in the ISOC Subsidiary model, it would be necessary to transfer the existing relationships to IETFAdminOrg. See the previous section for details on this. 5.2. IETFAdminOrg and the Relationship with IETF o The IETF would provide oversight into the governance of IETFAdminOrg, including seating part of the board. MDF: A majority of the board? 5.3. Oversight for IETFAdminOrg While IASA++ could continue to have an oversight structure populated by members of the IETF community, either the Subsidiary or Independent models involve the creation of an IETFAdminOrg which would need to have its governance structure defined. This structure needs to include the involvement of members with significant nonprofit governance experience, while also ensuring accountability to and involvement from the IETF Community. In order to achieve these objectives, the design team proposes a model similar to other nonprofits, in which IETFAdminOrg would be governed by a Board of Trustees. This board, the IASA Board (IB), acts to set strategic direction for IETF administrative matters, sets budgets, provides fiscal oversight, provides high-level oversight about major new projects, and so on. The board is also responsible for hiring and assessing the performance of the Executive Director (the highest-level staff director (see Section 5.5). The board works with staff who is empowered to carry out the operations as directed by the board. The staff is responsible for operating within the limits set by the board, and are accountable to the board. MDF: These is confusing to me at least. A clearer model would be for the = board to set high-level goals and make strategic decisions. The ExecD = should be accountable to the board, the staff would be accountable to = the ExecD. Otherwise we=E2=80=99re back to the confusion around = accountability and lines of authority that we have today. 5.4. Transparency Regardless of the chosen reorganization model, transparency deserves attention. As discussed in Section 4, this includes improving the timeliness of sharing of information and decisions, seeking comment on forthcoming decisions, and a a "reset" of expectations around MDF: Nit - s/and a a/and a/ delegated authority. In addition, there needs to be an agreement between the IETF community and the administrative entity about the where to draw the MDF: Nit - s/about the where/about where/ line between community's need for information, and the need to keep MDF: Nit - s/between community=E2=80=99s/between the community=E2=80=99s/ some business (or personnel) data confidential. 5.5. Staff Structure o Director of Operations. This person is responsible for meeting arrangements, IT, tools, managing contracts (including RFC Editor and IANA), and day-to-day budget management. MDF: This role sounds to me like the current IAD and seems quite = overloaded - I wonder about assigning some of these tasks elsewhere = (e.g. to the ExecD) It's worth considering short-term (3-5 years) and long-term (5-10+ years) plans differently. In the short term, we can continue to rely on our existing funding sources regardless of which organizational model we end up with for IASA 2.0, including the independent organization model. The role of ISOC as providing the funding to the IETF and agreeing to help us if we get to trouble should stay under all of the options, until or if a future funding model change changes MDF: Nit s/change// that. While ISOC continues to support IETF financially as they have previously, the different reorganization options affect the legal, contractual, and accounting related details. While continuing as-is is possible, adopting a a more predictable allocation of funding is MDF: Nit s/a a/a desirable (see Section 5.6.3), and in the subsidiary and independent options formal contracts about the funding are also necessary. The exact details of those contracts and contracting parties are for further study, but they do not need to change the fundamental arrangement that is in place today. Sometimes even administrative decisions can impact the nature or culture of the IETF, such as when improvements in remote attendance support are adopted. A clear interface between the community and the IETFAdminOrg is helpful in specifying what role the community and other parts of the system play. The nomcom- appointed board members and the Advisory Council have clearer MDF: Whether board members are nomcom-appointed or appointed via some = other mechanism is still an open question right? So this should probably = just say =E2=80=98board members=E2=80=99. Also, s/have clearer/have a = clearer role, and have a more community-focused role in the new arrangements to ensure that the community has a strong voice. o Clarify Overall Roles and Responsibilities: The reorganization is an opportunity to rethink what staff roles are needed, staff levels, whether to organize a function as a staff function or as contracted service to a vendor. All options are likely to provide clarified roles and responsibilities. However, in IASA++, some of lack of clarity may remain, as lack of MDF: Nit - s/some of lack/some lack/ clarity inherent in two organizations controlling resources may remain. In general the subsidiary and independent organisation models ensure better tha the IETF community and the IETF MDF: Nit - s/tha/that administrative functions have authority to perform exactly the kind of adminstration they want. The independent organization model eliminates all ambiquity about MDF: s/ambiquity/ambiguity the IETF having authority independent from ISOC over staff, funds, and decisions. Mat > On 1 Nov 2017, at 17:53, Jari Arkko wrote: >=20 > Thank you for the feedback we=E2=80=99ve received so far (incl. some = off-list). Much appreciated, and we are looking at it carefully. >=20 > I would like to ask for more people to look at the document, and do so = even before the meeting, here on this list. I believe Alissa=E2=80=99s = plan is to come out of Singapore with a sense of the community on which = direction to pursue, and that can be best achieved if at least some of = the substantive discussion can happen before our meeting, and we can = better prepare for the questions and ideas people will have. >=20 > The document is here: >=20 > https://tools.ietf.org/html/draft-haberman-iasa20dt-recs-01 >=20 > Jari for the design team >=20 > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 From nobody Mon Nov 6 13:27:19 2017 Return-Path: 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 019F713FB53 for ; Mon, 6 Nov 2017 13:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=ej5UpLrG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gaFyM9My 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 1SvkP3OwyS2o for ; Mon, 6 Nov 2017 13:27:15 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB57913FB39 for ; Mon, 6 Nov 2017 13:27:14 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 133AF20C69; Mon, 6 Nov 2017 16:27:14 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Mon, 06 Nov 2017 16:27:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=rneZ27KXbN4ODDwRwwqYE4GIBJeVEJiglnpOarBZDCs=; b=ej5UpLrG b5wo27eAG4QbBXgDvCR2Dzzj3MkKTEy83GiCadiHb1sJHT2uAqKKBY8FU0EQIko1 WJi86Kaq1m4uAxv5561iTtuATtRaRq1qCSBoflEm4wtjDe+VB5qphaWFfOWbPlVY whuIXweVOHYLYEwniTc5vtymxe/8/7yL1Az+xlFj9XuJw/01IuqQumLz/TeId2By 29TfID6VzLoiKE7NiLdOEgJLOVdfZQ3KT7rDdpUGmt1vwDb2RbRMRLMkhBUeIVlO xIbzJ4IXUsTbEh71SwEmi9bDNaBpWuffJ7mhC784gAJBBzbBRbmqn3OMLHcL3xsF KbItClqtlkIVMw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=rneZ27KXbN4ODDwRwwqYE4GIBJeVE JiglnpOarBZDCs=; b=gaFyM9MyJbLEjdK8IM7aH+hiX12afRU9D81PeFyAdyZYn kpcISUQlbTZxOEVBQ7L5pVCd3C5wrqTANPkHVKCewQAkyH6SR822jCQLEt3V5Tgt +FdITt9O2k6IoVyfwfnno9SF54+L+8hz1zuPLdYhb2YWMHYqFI4mxwuii1M09BYQ if212IgWWIMWnzzoq74KpYF0rB2lr35evixI2ApDYTY6GGDWS1Ux2EN5opmLTd4h 7BMjxErpU9az/k8dDsiI0eCYnV9/GSNb9HD76zhLfIhD9zyiGQtgiB3V2OPIXeyO GzVGs6lyyBA5HAfqUmJb2w/CoKN0DMl58ozEI07Qw== X-ME-Sender: Received: from alcoop-m-mx19.fios-router.home (pool-108-48-166-97.washdc.fios.verizon.net [108.48.166.97]) by mail.messagingengine.com (Postfix) with ESMTPA id B33017FA7E; Mon, 6 Nov 2017 16:27:13 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_72E71DEC-11BF-4C00-873C-05D3B840FD96" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Mon, 6 Nov 2017 16:27:13 -0500 Cc: Jari Arkko , iasa20@ietf.org Message-Id: <0329A33F-7E73-4EDC-9037-E12CF014AC5D@cooperw.in> References: To: Ted Hardie X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Iasa20] Thoughts on draft-haberman-iasa20dt-recs-01.txt X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 21:27:18 -0000 --Apple-Mail=_72E71DEC-11BF-4C00-873C-05D3B840FD96 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 1, 2017, at 10:11 PM, Ted Hardie wrote: >=20 >> Lastly,in the interests of full transparency, I think the Internet = Society has been a consistent source of support and insight since we = made the previous transition, and I generally favor the approaches which = maintain a strong relationship between the IETF and ISOC. I agree that = the changes in activities on both sides necessitate a re-examination of = how that relationship works, and if the most appropriate change is to a = subsidiary structure, I am ready to support that. But I disagree with = Richard's analysis that IASA++ is an inferior form of the subsidiary = approach. IASA++ could imply a much stronger integration with ISOC than = we have previously seen, and that could go in a variety of ways. =20 >>=20 >> To give one example, ISOC could decide in the course of the IASA++ = re-organization to use a more-contractor heavy approach to some of its = other work and to manage the overall costs by using the same contractors = for IETF work and other Internet Society work. That approach (similar to = the "task requester" approach used in some government agencies) would be = a change to the way the Internet Society works that would make the IETF = work a more natural fit to ISOC's other working methods. Put another = way, IASA++ is really an Internet Society reorg, and assessing whether = or not it is the right choice depends heavily on the extent to which = ISOC is interested in a re-org of that scope, which would necessarily = affect its other activities if it is to be successful. >=20 > Here I need more help to understand what you=E2=80=99re thinking. = I=E2=80=99ve been having trouble imagining the kinds of things we can = improve in IASA++. Your general point about the possibility of = integration as good/useful thing is taken. And I understand the more = contractor heavy organisational model. And I understand the benefits of = integration and synergy effects in general. What I=E2=80=99m having = trouble is understanding how they fit our case, and how they help solve = the problems about lack of clarity and clear lines of authority and = other things that we=E2=80=99ve found troublesome. >=20 > But I=E2=80=99m very interested in understanding what useful things we = could do here, as at least I could have missed many opportunities here = and probably the same is true of the rest of the design team. Can you = help us, e.g., by sketching some things that we could do here? >=20 >=20 > A recent example is the shifting of some accounting tasks related to = the IAOC from ISOC to a contract with AMS (actually an amendment to the = secretariat contract). In an IASA++ world with a tighter integration, = ISOC could have considered or implemented a move of its other accounting = requirements to an outside contractor, which the IETF would have then = shared. >=20 > As I said in my previous note, this approach very much depends on the = appetite of ISOC to have a reorg of facilities unrelated to the IETF, so = they were in greater alignment. That's a matter for the Trustees and = staff. I think this gets at an important point: regardless of which path we end = up taking, it will be crucial for ISOC to have the appetite needed for = the changes associated with the chosen path. This is as true for the = IASA++ option as for the others, in my reading of the DT document. Ted = used the shift to contractors as one hypothetical example of a change = that would require buy-in from both sides, but I think that is just one = possibility out of many that could come as part of going the IASA++ = route. So my take-away is that to adequately address the problems = articulated in the document, we shouldn=E2=80=99t be viewing IASA++ as a = status quo option, neither should ISOC, and both we and ISOC need to be = on board with that. Alissa =20 >=20 > I hope that example helps clarify that avenue of discussion, >=20 > regards, >=20 > Ted > =20 >=20 >=20 > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 --Apple-Mail=_72E71DEC-11BF-4C00-873C-05D3B840FD96 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 1, 2017, at 10:11 PM, Ted Hardie <ted.ietf@gmail.com> = wrote:

Lastly,in the interests of = full transparency, I think the Internet Society has been a consistent = source of support and insight  since we made the previous = transition, and I generally favor the approaches which maintain a strong = relationship between the IETF and ISOC.  I agree that the changes = in activities on both sides necessitate a re-examination of how that = relationship works, and if the most appropriate change is to a = subsidiary structure, I am ready to support that.  But I disagree = with Richard's analysis that IASA++ is an inferior form of the = subsidiary approach.  IASA++ could imply a much stronger = integration with ISOC than we have previously seen, and that could go in = a variety of ways. 

To give one = example, ISOC could decide in the course of the IASA++ re-organization = to use a more-contractor heavy approach to some of its other work and to = manage the overall costs by using the same contractors for IETF work and = other Internet Society work. That approach (similar to the "task = requester" approach used in some government agencies) would be a change = to the way the Internet Society works that would make the IETF work a = more natural fit to ISOC's other working methods.   Put = another way, IASA++ is really an Internet Society reorg, and assessing = whether or not it is the right choice depends heavily on the extent to = which ISOC is interested in a re-org of that scope, which would = necessarily affect its other activities if it is to be successful. =
Here I need more help to = understand what you=E2=80=99re thinking. I=E2=80=99ve been having = trouble imagining the kinds of things we can improve in IASA++. Your = general point about the possibility of integration as good/useful thing = is taken. And I understand the more contractor heavy organisational = model. And I understand the benefits of integration and synergy effects = in general. What I=E2=80=99m having trouble is understanding how they = fit our case, and how they help solve the problems about lack of clarity = and clear lines of authority and other things that we=E2=80=99ve found = troublesome.

But= I=E2=80=99m very interested in understanding what useful things we = could do here, as at least I could have missed many opportunities here = and probably the same is true of the rest of the design team. Can you = help us, e.g., by sketching some things that we could do = here?

A recent example is the shifting of = some accounting tasks related to the IAOC from ISOC to a contract with = AMS (actually an amendment to the secretariat contract).  In an = IASA++ world with a tighter integration, ISOC could have considered or = implemented a move of its other accounting requirements to an outside = contractor, which the IETF would have then shared.

As I said in my previous = note, this approach very much depends on the appetite of ISOC to have a = reorg of facilities unrelated to the IETF, so they were in greater = alignment.  That's a matter for the Trustees and = staff.

I think this gets at an important point: = regardless of which path we end up taking, it will be crucial for ISOC = to have the appetite needed for the changes associated with the chosen = path. This is as true for the IASA++ option as for the others, in my = reading of the DT document. Ted used the shift to contractors as one = hypothetical example of a change that would require buy-in from both = sides, but I think that is just one possibility out of many that could = come as part of going the IASA++ route. So my take-away is that to = adequately address the problems articulated in the document, we = shouldn=E2=80=99t be viewing IASA++ as a status quo option, neither = should ISOC, and both we and ISOC need to be on board with = that.

Alissa
 

I hope that example helps clarify that avenue of = discussion,

regards,

Ted
 


_______________________________________________
iasa20 = mailing list
iasa20@ietf.org
https://www.ietf.org/mailman/listinfo/iasa20

= --Apple-Mail=_72E71DEC-11BF-4C00-873C-05D3B840FD96-- From nobody Mon Nov 6 14:55:25 2017 Return-Path: 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 AFE5013FAC5 for ; Mon, 6 Nov 2017 14:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=team.neustar 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 wEJ77G9-vq-j for ; Mon, 6 Nov 2017 14:55:22 -0800 (PST) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (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 4FA5113F698 for ; Mon, 6 Nov 2017 14:55:22 -0800 (PST) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA6Mrfuw030344 for ; Mon, 6 Nov 2017 17:55:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=team.neustar; h=from : to : subject : date : message-id : content-type : mime-version; s=selector1; bh=2jWrckDPatmfg9L/+FcCxzhM3l9MM6TQQ+CPQUV87+0=; b=na3yqvnrwePrZQiCzt8SU0PYksg6tEtgZN5Vws68FYHWvjoR1qP06JGzKkKOBxzzgH1t r+X7SJ9TmDtpCVfRVwoDEi7l7XS1Bj2z2woXslHat2VAhNh8POO5edZmrrflkYZwpJK0 iMzRwaUSAtpK6dGPubDdmnUSbUBUsbvRtAZpso4ZF8bQDe6otdIdZLUZYMaWaTstM9W/ s91Pxnmkv9JpyJM5eJumBbG7becuuB6KPqOvruEp0d6PuVUABEvkD51q3689KfblWaNI M70VhA2cMTR2gEdD9p6HwGOg4ejZTJZMLWDpgmQwE4hQedmxg5y5VHUu8IYOsv4xL68c UQ== Received: from stntexhc10.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 2e18bh7p1j-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 06 Nov 2017 17:55:19 -0500 Received: from STNTEXMB11.cis.neustar.com ([169.254.1.47]) by stntexhc10.cis.neustar.com ([169.254.4.36]) with mapi id 14.03.0279.002; Mon, 6 Nov 2017 17:55:18 -0500 From: "Peterson, Jon" To: "iasa20@ietf.org" Thread-Topic: agenda for singapore Thread-Index: AQHTV1JR/HnfPDPB/0C97ckMIOKUhQ== Date: Mon, 6 Nov 2017 22:55:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.30] Content-Type: multipart/alternative; boundary="_000_D62628531F03F3jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-06_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711060312 Archived-At: Subject: [Iasa20] agenda for singapore X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 22:55:24 -0000 --_000_D62628531F03F3jonpetersonneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The agenda for IASA 2.0 in Singapore is up on the materials page: https://datatracker.ietf.org/doc/agenda-100-iasa20/ Please do take a gander, let me know if there's anything different we shoul= d be doing. Thanks! Jon Peterson Neustar, Inc. --_000_D62628531F03F3jonpetersonneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <9C75F2EC0B90A4469178B7AA11D5A654@neustar.biz> Content-Transfer-Encoding: quoted-printable

The agenda for IASA 2.0 in Singapore is up on the materials page:


Please do take a gander, let me know if there's anything different we = should be doing.

Thanks!

Jon Peterson
Neustar, Inc.
--_000_D62628531F03F3jonpetersonneustarbiz_-- From nobody Tue Nov 7 07:59:21 2017 Return-Path: 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 CB8E11332CD for ; Tue, 7 Nov 2017 07:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 SGtTM-ovi3KB for ; Tue, 7 Nov 2017 07:59:17 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95B0F13478C for ; Tue, 7 Nov 2017 07:51:47 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id i198so11251496ywe.7 for ; Tue, 07 Nov 2017 07:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dVjjOZemdqwjBBmksVEBWgyok5yvIpw+zTKDoaEjegA=; b=llExolugEoB71GMzzwKAQoNQ0DsRTXlWy4syfba+76tvdixz9nuP3U7bDXCTSUx201 eNDMd6sZp5dDrfCGiw7665hAdVmmBI03hkNFm9uiDe88OBeBmDjX7IRonuwPCG0+lgv9 MPBcdzFOnUxUyZRnVs/CnWp8i8afcuN0/uem8Z846CGOauIGrAPSLDJfi752irDDIuFZ UjnebkGgcRKxWfLvaQwu/glzvsBVKsuPKS1SIGf//KPYB1dCMn5/vseApNbZ1qWOSw/b M3BSmGwsY7YwekOheE0LxUYBDxQUv37ga+8cQfURR5en7gwp/pbkuEv1H0y3weTMoqhS xz1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dVjjOZemdqwjBBmksVEBWgyok5yvIpw+zTKDoaEjegA=; b=fnHYoiboqAWDAPgZGvDeX692ktjP6p+wyNNDVP1jYXKdc3ZKUxsFvKM4DygGiSrUug 0D5c/V8qhXJTilWuB46dLD5BVUlkCEvBLgjvDV9Ny3FtSgDBj21Fy4IpLPPZGII3Kx7Y 7tgzlVpGBMqy+z753Wz7hNF/t+s+e4IERYAW2yeHP/699unepcXlgon4XmkBNmYjpqna 9sbLRsgXdy5DKhEx/7ApgmvsIL1iWB4rhjERKgDKeFSo9iSBeWE00VdJ6x/b+0kl4RRW 78ABrKSSza3mDv2/kgEX7jrUIHPpfxPK3IZMuOTvcTyShst2UCZsARyLQ45bJw2a8HrT Ms7w== X-Gm-Message-State: AMCzsaWCUm7WrVaG0/FVKgYdH7kub/gnx1H1Hr6bKvYfbr8t1EwYCoaB p5d3CGc8yU6D62HxFLnN+pmlqRivaoFdq75unxA= X-Google-Smtp-Source: ABhQp+QYUCqrZiUGHZk+Ehhg2Mw5znUzSZb8VkjvDgf06XKirbrhddPtd9b5as39y1RR8m7iFLS2vra6Zoae8o3XUQs= X-Received: by 10.37.41.4 with SMTP id p4mr11911794ybp.354.1510069906530; Tue, 07 Nov 2017 07:51:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.162.204 with HTTP; Tue, 7 Nov 2017 07:51:46 -0800 (PST) In-Reply-To: <0329A33F-7E73-4EDC-9037-E12CF014AC5D@cooperw.in> References: <0329A33F-7E73-4EDC-9037-E12CF014AC5D@cooperw.in> From: Spencer Dawkins at IETF Date: Tue, 7 Nov 2017 09:51:46 -0600 Message-ID: To: Alissa Cooper Cc: Ted Hardie , iasa20@ietf.org, Jari Arkko Content-Type: multipart/alternative; boundary="94eb2c14dafe5d68f4055d668ce9" Archived-At: Subject: Re: [Iasa20] Thoughts on draft-haberman-iasa20dt-recs-01.txt X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 15:59:20 -0000 --94eb2c14dafe5d68f4055d668ce9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Speaking as an interested lurker ... On Mon, Nov 6, 2017 at 3:27 PM, Alissa Cooper wrote: > > On Nov 1, 2017, at 10:11 PM, Ted Hardie wrote: > >> >> Lastly,in the interests of full transparency, I think the Internet >> Society has been a consistent source of support and insight since we ma= de >> the previous transition, and I generally favor the approaches which >> maintain a strong relationship between the IETF and ISOC. I agree that = the >> changes in activities on both sides necessitate a re-examination of how >> that relationship works, and if the most appropriate change is to a >> subsidiary structure, I am ready to support that. But I disagree with >> Richard's analysis that IASA++ is an inferior form of the subsidiary >> approach. IASA++ could imply a much stronger integration with ISOC than= we >> have previously seen, and that could go in a variety of ways. >> >> To give one example, ISOC could decide in the course of the IASA++ >> re-organization to use a more-contractor heavy approach to some of its >> other work and to manage the overall costs by using the same contractors >> for IETF work and other Internet Society work. That approach (similar to >> the "task requester" approach used in some government agencies) would be= a >> change to the way the Internet Society works that would make the IETF wo= rk >> a more natural fit to ISOC's other working methods. Put another way, >> IASA++ is really an Internet Society reorg, and assessing whether or not= it >> is the right choice depends heavily on the extent to which ISOC is >> interested in a re-org of that scope, which would necessarily affect its >> other activities if it is to be successful. >> >> >> Here I need more help to understand what you=E2=80=99re thinking. I=E2= =80=99ve been >> having trouble imagining the kinds of things we can improve in IASA++. Y= our >> general point about the possibility of integration as good/useful thing = is >> taken. And I understand the more contractor heavy organisational model. = And >> I understand the benefits of integration and synergy effects in general. >> What I=E2=80=99m having trouble is understanding how they fit our case, = and how >> they help solve the problems about lack of clarity and clear lines of >> authority and other things that we=E2=80=99ve found troublesome. >> >> But I=E2=80=99m very interested in understanding what useful things we c= ould do >> here, as at least I could have missed many opportunities here and probab= ly >> the same is true of the rest of the design team. Can you help us, e.g., = by >> sketching some things that we could do here? >> >> > A recent example is the shifting of some accounting tasks related to the > IAOC from ISOC to a contract with AMS (actually an amendment to the > secretariat contract). In an IASA++ world with a tighter integration, IS= OC > could have considered or implemented a move of its other accounting > requirements to an outside contractor, which the IETF would have then > shared. > > As I said in my previous note, this approach very much depends on the > appetite of ISOC to have a reorg of facilities unrelated to the IETF, so > they were in greater alignment. That's a matter for the Trustees and sta= ff. > > > I think this gets at an important point: regardless of which path we end > up taking, it will be crucial for ISOC to have the appetite needed for th= e > changes associated with the chosen path. This is as true for the IASA++ > option as for the others, in my reading of the DT document. Ted used the > shift to contractors as one hypothetical example of a change that would > require buy-in from both sides, but I think that is just one possibility > out of many that could come as part of going the IASA++ route. So my > take-away is that to adequately address the problems articulated in the > document, we shouldn=E2=80=99t be viewing IASA++ as a status quo option, = neither > should ISOC, and both we and ISOC need to be on board with that. > +1 Alissa, with the added observation that we're doing the IASA 2.0 exercise as a 10-year review; if that's how long until the next review, we should definitely be looking past the status quo (as a community), and we probably can't do this level of review very often, so 10 years is a reasonable estimate for the next time we do it. Spencer > > Alissa > > > > I hope that example helps clarify that avenue of discussion, > > regards, > > Ted > > > > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 > > > > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 > > --94eb2c14dafe5d68f4055d668ce9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Speaking as an interested lurker ...

On Mon, Nov 6, 2017 at 3:27 PM, Alissa = Cooper <alissa@cooperw.in> wrote:

On Nov 1, 2017, at 10:11 PM, Ted Hardie <ted.ietf@gmail.com&g= t; wrote:

Lastly,in the inte= rests of full transparency, I think the Internet Society has been a consist= ent source of support and insight=C2=A0 since we made the previous transiti= on, and I generally favor the approaches which maintain a strong relationsh= ip between the IETF and ISOC.=C2=A0 I agree that the changes in activities = on both sides necessitate a re-examination of how that relationship works, = and if the most appropriate change is to a subsidiary structure, I am ready= to support that.=C2=A0 But I disagree with Richard's analysis that IAS= A++ is an inferior form of the subsidiary approach.=C2=A0 IASA++ could impl= y a much stronger integration with ISOC than we have previously seen, and t= hat could go in a variety of ways.=C2=A0

To give one example, ISOC = could decide in the course of the IASA++ re-organization to use a more-cont= ractor heavy approach to some of its other work and to manage the overall c= osts by using the same contractors for IETF work and other Internet Society= work. That approach (similar to the "task requester" approach us= ed in some government agencies) would be a change to the way the Internet S= ociety works that would make the IETF work a more natural fit to ISOC's= other working methods.=C2=A0=C2=A0 Put another way, IASA++ is really an In= ternet Society reorg, and assessing whether or not it is the right choice d= epends heavily on the extent to which ISOC is interested in a re-org of tha= t scope, which would necessarily affect its other activities if it is to be= successful.
Here I need more help to understand what you=E2=80=99re= thinking. I=E2=80=99ve been having trouble imagining the kinds of things w= e can improve in IASA++. Your general point about the possibility of integr= ation as good/useful thing is taken. And I understand the more contractor h= eavy organisational model. And I understand the benefits of integration and= synergy effects in general. What I=E2=80=99m having trouble is understandi= ng how they fit our case, and how they help solve the problems about lack o= f clarity and clear lines of authority and other things that we=E2=80=99ve = found troublesome.

But I=E2=80=99m very interested= in understanding what useful things we could do here, as at least I could = have missed many opportunities here and probably the same is true of the re= st of the design team. Can you help us, e.g., by sketching some things that= we could do here?


A recent example is the shifting of some accounting = tasks related to the IAOC from ISOC to a contract with AMS (actually an ame= ndment to the secretariat contract).=C2=A0 In an IASA++ world with a tighte= r integration, ISOC could have considered or implemented a move of its othe= r accounting requirements to an outside contractor, which the IETF would ha= ve then shared.

As I said in my previous note, thi= s approach very much depends on the appetite of ISOC to have a reorg of fac= ilities unrelated to the IETF, so they were in greater alignment.=C2=A0 Tha= t's a matter for the Trustees and staff.
<= /blockquote>

I think this gets at an important po= int: regardless of which path we end up taking, it will be crucial for ISOC= to have the appetite needed for the changes associated with the chosen pat= h. This is as true for the IASA++ option as for the others, in my reading o= f the DT document. Ted used the shift to contractors as one hypothetical ex= ample of a change that would require buy-in from both sides, but I think th= at is just one possibility out of many that could come as part of going the= IASA++ route. So my take-away is that to adequately address the problems a= rticulated in the document, we shouldn=E2=80=99t be viewing IASA++ as a sta= tus quo option, neither should ISOC, and both we and ISOC need to be on boa= rd with that.

+1 Alissa, = with the added observation that we're doing the IASA 2.0 exercise as a = 10-year review; if that's how long until the next review, we should def= initely be looking past the status quo (as a community), and we probably ca= n't do this level of review very often, so 10 years is a reasonable est= imate for the next time we do it.

Spencer
=C2=A0

Alissa
=C2=A0


I hope that example he= lps clarify that avenue of discussion,

regards,

Ted
=C2=A0


_______________________________________________
iasa20 mailing list=
iasa20@ietf.org
https://www.ietf.org/mailman/listinfo/iasa20


____________________________________________= ___
iasa20 mailing list
iasa20@ietf.org
https://www.ietf.org/mailman/listinfo/iasa20

--94eb2c14dafe5d68f4055d668ce9-- From nobody Tue Nov 7 09:28:56 2017 Return-Path: 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 1D03E133065 for ; Tue, 7 Nov 2017 09:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=vtF+uXjz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IN35aioI 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 tzUzF8cCeM4t for ; Tue, 7 Nov 2017 09:28:52 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB89133038 for ; Tue, 7 Nov 2017 09:28:51 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D2C5020DF6 for ; Tue, 7 Nov 2017 12:28:50 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 07 Nov 2017 12:28:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=MnlG6Kyl6LxexQ+aC9njxbTKgr2kV9hxBcpRU1zR1pU=; b=vtF+uXjz TBGGeAFvPNhZsDHGDq+2xyy++tu9e9sCPACdfov/eFawS8MLIT+ihfWJp8BMjKRh S8XaH6hXKSCZ94YUruJcuRo23Orb+3k+Ayi1dgu2yh7a1A9fwaJ1RUynLz5ScFeT +2mESZWqjPFJKo7fu8d0OZvAni/E+lC2DRaZSdM62PvtzLjtOqIwKKUzOYJEcbt0 EBvRjRioaPAdtCOU06RnlP7H4QTF9q3nqWLvgMS4JPzoDSHJUg+pUP8cRsQuus9A SR9o9wVC6LTnRncTybjH0oo/uDB69H+vBNRY8QEGDhVBAmNHd5e+4tfjM3EH6yEx nIkxw6EFmB6Yfg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=MnlG6Kyl6LxexQ+aC9njxbTKgr2kV 9hxBcpRU1zR1pU=; b=IN35aioItjdhghWQIHSKoQGqk6Dkg6XKWkt9CjH3kpIk2 HmUXDKCJJXxzlI7NXkarQOfYMW+K8AlK1Gk4z+OWwfIPk6N/GgFIVt3gNi2jya4v ByKkjXSNfpGkolxIrqwJfPO7Vd4za66fhBGl6i/n2PMiOZ5+epP2/rvMPdbiCDqK RZHYAMvmglrsJiYFkTKg6J9rMnmjEUw9ohDqUuxkCuJ513RyiLkRuqvL2ruX2II3 QpKNlFLrot62UtaghXldcYIDYdNZb3thsWaMdcGpAxYPYGXk936Q7YCdy2HQMFNx FlArbr/clCOzTS/7yLiMCaPfHBAwiRX/TJ4v62oWA== X-ME-Sender: Received: from sjc-alcoop-88113.cisco.com (unknown [128.107.241.173]) by mail.messagingengine.com (Postfix) with ESMTPA id 401D67FAD5 for ; Tue, 7 Nov 2017 12:28:50 -0500 (EST) From: Alissa Cooper Content-Type: multipart/alternative; boundary="Apple-Mail=_EDA71AEF-C125-473A-A3BD-46752E646266" Message-Id: <21B7D3B6-BFBA-4895-B549-8E8980ABB1A0@cooperw.in> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Tue, 7 Nov 2017 12:28:48 -0500 References: To: "iasa20@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Iasa20] agenda for singapore X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 17:28:54 -0000 --Apple-Mail=_EDA71AEF-C125-473A-A3BD-46752E646266 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Glad to see some folks have given some consideration to the design = team=E2=80=99s work and posted comments to the list. Hoping for more = before next week.=20 I wanted to share a few thoughts about the agenda for the BoF. Personally I think the design team has covered a lot of ground since = IETF 99, and the document provides a lot of solid material to work from. = My goal coming out of the BoF is to have a sense of direction from the = community for this effort going forward. I=E2=80=99d like to understand = how people assess the options described in the document against the = problem statement and goals laid out at the beginning. Ideally that = sense of direction will be clear enough to then begin planting the seeds = for the streams of work that will be needed to actually effectuate the = changes (IETF document updates, possibly accompanied by WG chartering, = work with the ISOC BoT, etc.). I will admit that I feel some urgency to move this work forward. We=E2=80=99= ve been discussing it for awhile, our interim IAD is on contract for a = finite period of time, our budget and sponsorship activities stand to = benefit from getting clarity about the path here, and as Gonzalo = mentioned the ISOC BoT has taken steps to prepare for more intensive = work on this in the coming months. So I=E2=80=99ve got my fingers = crossed that we can enter that more intensive phase with the = community=E2=80=99s backing coming out of Singapore. Thanks, Alissa > On Nov 6, 2017, at 5:55 PM, Peterson, Jon = wrote: >=20 >=20 > The agenda for IASA 2.0 in Singapore is up on the materials page: >=20 > https://datatracker.ietf.org/doc/agenda-100-iasa20/ = >=20 > Please do take a gander, let me know if there's anything different we = should be doing. >=20 > Thanks! >=20 > Jon Peterson > Neustar, Inc. > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 --Apple-Mail=_EDA71AEF-C125-473A-A3BD-46752E646266 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Glad to see some folks have given some = consideration to the design team=E2=80=99s work and posted comments to = the list. Hoping for more before next week. 
I wanted to share a few thoughts about = the agenda for the BoF.

Personally I think = the design team has covered a lot of ground since IETF 99, and the = document provides a lot of solid material to work from. My goal coming = out of the BoF is to have a sense of direction from the community for = this effort going forward. I=E2=80=99d like to understand how people = assess the options described in the document against the problem = statement and goals laid out at the beginning. Ideally that sense of = direction will be clear enough to then begin planting the seeds for the = streams of work that will be needed to actually effectuate the changes = (IETF document updates, possibly accompanied by WG chartering, work with = the ISOC BoT, etc.).

I will admit that I = feel some urgency to move this work forward. We=E2=80=99ve been = discussing it for awhile, our interim IAD is on contract for a finite = period of time, our budget and sponsorship activities stand to benefit = from getting clarity about the path here, and as Gonzalo mentioned the = ISOC BoT has taken steps to prepare for more intensive work on this in = the coming months. So I=E2=80=99ve got my fingers crossed that we can = enter that more intensive phase with the community=E2=80=99s backing = coming out of Singapore.

Thanks,
Alissa


On = Nov 6, 2017, at 5:55 PM, Peterson, Jon <jon.peterson@team.neustar> wrote:


The agenda for IASA 2.0 in Singapore is up on the = materials page:


Please do take a gander, let me know if there's anything = different we should be doing.

Thanks!

Jon Peterson
Neustar, Inc.
_______________________________________________
iasa20 = mailing list
iasa20@ietf.org
https://www.ietf.org/mailman/listinfo/iasa20

= --Apple-Mail=_EDA71AEF-C125-473A-A3BD-46752E646266-- From nobody Tue Nov 7 12:22:01 2017 Return-Path: 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 9A4511241F5 for ; Tue, 7 Nov 2017 12:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham 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 LIi7diHHMbIk for ; Tue, 7 Nov 2017 12:21:57 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id D9A0A1200C5 for ; Tue, 7 Nov 2017 12:21:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3986E2D194; Tue, 7 Nov 2017 22:21:55 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgS6nUsV65mf; Tue, 7 Nov 2017 22:21:53 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id DA8342CFCF; Tue, 7 Nov 2017 22:21:53 +0200 (EET) (envelope-from jari.arkko@piuha.net) From: Jari Arkko Message-Id: <6331F9A5-6469-43A1-B013-8B4EBC36D60F@piuha.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_74A4B4D2-394A-4144-95F7-0DE91B61F283" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 7 Nov 2017 22:21:53 +0200 In-Reply-To: <0329A33F-7E73-4EDC-9037-E12CF014AC5D@cooperw.in> Cc: Ted Hardie , iasa20@ietf.org To: Alissa Cooper References: <0329A33F-7E73-4EDC-9037-E12CF014AC5D@cooperw.in> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Thoughts on draft-haberman-iasa20dt-recs-01.txt X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 20:22:00 -0000 --Apple-Mail=_74A4B4D2-394A-4144-95F7-0DE91B61F283 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> But I=E2=80=99m very interested in understanding what useful things = we could do here, as at least I could have missed many opportunities = here and probably the same is true of the rest of the design team. Can = you help us, e.g., by sketching some things that we could do here? >>=20 >>=20 >> A recent example is the shifting of some accounting tasks related to = the IAOC from ISOC to a contract with AMS (actually an amendment to the = secretariat contract). In an IASA++ world with a tighter integration, = ISOC could have considered or implemented a move of its other accounting = requirements to an outside contractor, which the IETF would have then = shared. >>=20 >> As I said in my previous note, this approach very much depends on the = appetite of ISOC to have a reorg of facilities unrelated to the IETF, so = they were in greater alignment. That's a matter for the Trustees and = staff. >=20 > I think this gets at an important point: regardless of which path we = end up taking, it will be crucial for ISOC to have the appetite needed = for the changes associated with the chosen path. This is as true for the = IASA++ option as for the others, in my reading of the DT document. Ted = used the shift to contractors as one hypothetical example of a change = that would require buy-in from both sides, but I think that is just one = possibility out of many that could come as part of going the IASA++ = route. So my take-away is that to adequately address the problems = articulated in the document, we shouldn=E2=80=99t be viewing IASA++ as a = status quo option, neither should ISOC, and both we and ISOC need to be = on board with that. I agree with everything that was said above by you Ted and Alissa. The use of contractors is a great example, makes a lot of sense, and I = think Alissa and the team has already made significant steps in that = direction.=20 I do want to say though outside of that example, the crux is finding the = concrete things that we can do (and my personal ability to imagine what = those might be seems a bit limited at the moment). I=E2=80=99ll also say = that there are things we cannot do as freely as one might perhaps think = when there=E2=80=99s no formal separation between entities, which might = limit some things e.g. around managing staff. Although of course the = contractor model makes some of those issues not so relevant or at least = limits their impact to a small set of people. Jari --Apple-Mail=_74A4B4D2-394A-4144-95F7-0DE91B61F283 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

But I=E2=80=99m very = interested in understanding what useful things we could do here, as at = least I could have missed many opportunities here and probably the same = is true of the rest of the design team. Can you help us, e.g., by = sketching some things that we could do here?

A recent example is the shifting of = some accounting tasks related to the IAOC from ISOC to a contract with = AMS (actually an amendment to the secretariat contract).  In an = IASA++ world with a tighter integration, ISOC could have considered or = implemented a move of its other accounting requirements to an outside = contractor, which the IETF would have then shared.

As I said in my previous = note, this approach very much depends on the appetite of ISOC to have a = reorg of facilities unrelated to the IETF, so they were in greater = alignment.  That's a matter for the Trustees and = staff.

I think this gets at an important = point: regardless of which path we end up taking, it will be crucial for = ISOC to have the appetite needed for the changes associated with the = chosen path. This is as true for the IASA++ option as for the others, in = my reading of the DT document. Ted used the shift to contractors as one = hypothetical example of a change that would require buy-in from both = sides, but I think that is just one possibility out of many that could = come as part of going the IASA++ route. So my take-away is that to = adequately address the problems articulated in the document, we = shouldn=E2=80=99t be viewing IASA++ as a status quo option, neither = should ISOC, and both we and ISOC need to be on board with = that.

I = agree with everything that was said above by you Ted and = Alissa.

The use of contractors is a = great example, makes a lot of sense, and I think Alissa and the team has = already made significant steps in that direction. 

I do want to say though outside of that example, = the crux is finding the concrete things that we can do (and my personal = ability to imagine what those might be seems a bit limited at the = moment). I=E2=80=99ll also say that there are things we cannot do as = freely as one might perhaps think when there=E2=80=99s no formal = separation between entities, which might limit some things e.g. around = managing staff. Although of course the contractor model makes some of = those issues not so relevant or at least limits their impact to a small = set of people.

Jari

= --Apple-Mail=_74A4B4D2-394A-4144-95F7-0DE91B61F283-- From nobody Tue Nov 7 16:51:14 2017 Return-Path: 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 112BA12751F for ; Tue, 7 Nov 2017 16:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 x4tzSJyj1kSl for ; Tue, 7 Nov 2017 16:51:10 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875AB1270AE for ; Tue, 7 Nov 2017 16:51:10 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id b6so731020pfh.7 for ; Tue, 07 Nov 2017 16:51:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=W2J//txYAi4MESAuu8P/2oV1VhzzPVqLuJb8mENCj80=; b=fPRFIkl2ygBpEKuCGgtllnvuju7SomMVclvYMQjRKsIi0GORBFXfP2kx6+VW6qzzz1 eclJGhQRpjSPqLLYXXEvTK0pfkVWGvSKyOaRJIyUkaREKPvHWDNTUBT1NqJSBwODzRPX 4Bd5f9yyQvvg+eLiHYPi2nPGUBtthgZ/Ep38uu1m4k6L5bA2x7BxtB13yalwK33tBqd2 70x04KBm+t6dsPzOWRmdj1hSxa37o7Zmmf7ASyztafqybjMm1p0Q9k9ChAdXzI8SJaYY +xX3Ij2AV5Wk8+uGvr7H/skSNIMO3WklW+DNUDCtFdmqUY4A4Xkc2ZSCVohhtkRYTUck olVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=W2J//txYAi4MESAuu8P/2oV1VhzzPVqLuJb8mENCj80=; b=qlcF8upQPGgoVstYTnqEyJVlBy2XVze1EausCZTyM6dUZlqmVqs3BYJjy+O/75+BeQ 74D07zaTJyXCOpxRV1skmgHsS5gJZvIt7f584Q8Hk11QK5xfwesab5nHlbYbW8WQHfmE OL2z4CHV3QMXVXBAP/zWjI3G0vSsj06ziiwtq//l/oAoLWa061x28p+F+q3r0EXd0KGS onBzoC4x6ek2BrXUfCp1Jn5LlpmR5nyN/JVe1+QnYgU194pmms6CRckU1HOTcnHeOG4N iXN8GSMTLMKyBjC/TnnbRAyMoCdkBPaVsMY+Rk7IspYlTxPhn7KcHAdDZFSi0X2bwS6a aZ6g== X-Gm-Message-State: AJaThX4S1BiEfAV1uen5oLiu/P3QzIJLga4kb0HjCk1XYNAnwjhJVZ7K fxfnlw9R/AlievIQzYrN8O/PZNCH X-Google-Smtp-Source: ABhQp+QY8m3NKILjKIbHWSq4f7kOKfZG+OL9kI2EybSg76Zsop+wADxEzs1htvoc2HYkW41l3a650w== X-Received: by 10.99.61.70 with SMTP id k67mr529952pga.113.1510102269732; Tue, 07 Nov 2017 16:51:09 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id d89sm4932080pfb.121.2017.11.07.16.51.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 16:51:08 -0800 (PST) From: Bob Hinden Content-Type: multipart/signed; boundary="Apple-Mail=_EE88C87B-F720-4F52-B2E7-251660BB283B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Tue, 7 Nov 2017 16:51:07 -0800 Cc: Bob Hinden To: iasa20@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Iasa20] Comments on X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 00:51:13 -0000 --Apple-Mail=_EE88C87B-F720-4F52-B2E7-251660BB283B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Thanks for putting this together, I think it is an improvement over the = earlier version. I have a lot of comments, but will stick with what I see is the high = level issue. I think the basic conflict in the document is that it wants to not make = any change in how the IETF=E2=80=99s standardization works, but at the = same time wants to make the IETF more independent and in control of what = it does. I don=E2=80=99t think this is possible. We currently have a = model where financial decisions are kept very separate from the = standardization activities. When, for example, the IESG decides it = wants the IETF to do something it hasn=E2=80=99t done before, there is = never a discussion about how much does this cost and does it fit within = the budget. I use the IESG as an example, but it the same for the IAB, = IRTF, and RFC-Editor. We have the luxury of operating this way because = we know that ISOC will pick up the extra costs. To make a very rough = analogy, we are the teenagers still living at home, but wanting complete = independence and a bigger allowance. Are we willing to move out, get a = job, pay for an apartment, etc. and become independent of our parents? = I read a lot of things in this document wanting to have it both ways. If we want to be more independent (especially in the Subsidiary and = Independent models), I think this way of operating will need to change. = The IETF will have to become like an conventional organization where = finance is part of most decisions. For example, if the IESG decides to = add a new area, add ADs, add working groups, new tools, have an interim = meeting, or something else, it will need to know this fits in the = current budget. The IESG will need to have a budget, and live within = it=E2=80=99s budget. It will need to make the tradeoff between = something new and stopping some existing activity, or defer the new work = until more funding can be found. The IETFAdminOrg (staff and board) = won=E2=80=99t be able to do this because they don=E2=80=99t have enough = information to make good tradeoffs. More importantly, we will get = better decisions by having the IESG making these decisions. If we don=E2=80=99t do something like this where finance is part of what = the IESG, IAB, RFC-Editor, and IRTF do, I don=E2=80=99t think we will be = able to move away from model where ISOC is the financial backstop with = everything else that comes along with this. Otherwise we will = continue to live in the world where we pretend that money doesn=E2=80=99t = exist. We can=E2=80=99t really become independent if we continue to = live in this world. I think this will be necessary if we want to become an ISOC Subsidiary = or Independent organization. If we don=E2=80=99t want to do this, then = we should focus on improving and clarifying our relationship with ISOC. = Something like the IASA++ model. I am not against the IETF becoming an ISOC Subsidiary (complete = Independence is not practical as far as I can tell), but think we need = to be realistic about what it means to do this. I don=E2=80=99t think = the changes can be limited to a separate IETFAdminOrg if we want it to = work. Thanks, Bob --Apple-Mail=_EE88C87B-F720-4F52-B2E7-251660BB283B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloCVPsACgkQrut0EXfn u6g4Ygf8DXeejB9lCrE2GhTHLl2FXurkWCv/EDbAorInlbV/8A919PLvx13P+xJb eekPJhupY0h0e7Xd4zqoObuI4VuHu6hlm78AHn3C50w5ZcUHxDVP4Qp1yc2UzyPM eHNi3uPzwauXYXntHHkcJzpLzwWst9dBKzQAn8PI2kYW1IXVw2C1beOk5y86ZFzy lga//f5CtvPSWVtXQTFXdXyztyEc0E5OshKL21DWzStvDfyu6ag0lhVECWav/HaZ FdzaNpF2BqeKggjPP3oXRNZjfuu3qhcL5dT2aNTo4EecaYuH4+0PvZb/LvYH2eL/ UNUpfNkYD0zhpinOx76hMln3xbwxtA== =70Na -----END PGP SIGNATURE----- --Apple-Mail=_EE88C87B-F720-4F52-B2E7-251660BB283B-- From nobody Tue Nov 7 17:55:09 2017 Return-Path: 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 8AFA112EA24 for ; Tue, 7 Nov 2017 17:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vapqm96ZlfvB for ; Tue, 7 Nov 2017 17:55:05 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB5812EB04 for ; Tue, 7 Nov 2017 17:55:02 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id y5so855840pgq.7 for ; Tue, 07 Nov 2017 17:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5zIHKSUAF+GRGeCS8hELxdNLtjrb3GVnXHYFtkTSLMU=; b=kYlLxV4FLc7DZsch5QoKh5/48BmIhSyDYP1NIliZha+5TUrehI8mKfFPV7Xr6Yhwnj opk95tULKTD0hd5jX61OJkun/n7gAmqlSkaeHjfBzEHydv8rbyKD++A61rsDCh5znGqV H6LjQZ6ipKQCcjUbxHsmScfFs2g0dxrVXc2pwiv0W/gMHz7FC5EHTeVSZzIGDf9OIAg+ dUaC/wRxzZTMeFSEpgmrmtCbINQ7RMHcYqJP8Av0hWmcPdzgCcjbHKCZehcp1UrG2/77 CORPXyIh/ixfdOJvUAlOrdCiXohEAfwEbZjDgTzBDD9MDGQmyWKOGzPlPJEJif/uV4XZ w9gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=5zIHKSUAF+GRGeCS8hELxdNLtjrb3GVnXHYFtkTSLMU=; b=cE1Z8/ghoC5alfDaA2rqanzk4iYD8Y0OmbLHLntctdFXtJ6l/lIAcuZpNI7EAt4qC/ yD7nOBtnU3HgPmLnh3yvkR4tG+DHfFv51UqXrYAsZpRMASPgsOMUfqADCTfj30bIZ1DA Br6pUlU68Z4PJAZcvtlxvJ69R9+hCi8nltfikwu6BPQ/CVUGURcC8VD0ZNRL5F38FMYP 2U045xCV4b50RPmp8mrkh+nBOKQgZq4tzwodOn+zkSt/SqQI0be3iSmL7sYQjFRQo8rd g2yKPg4WYJRhlC4bTLbP1crymdcozvMRIAlmzpEE4qjuNtilj6F8KKy+j33rN2KFWWx7 +D+A== X-Gm-Message-State: AJaThX6WhqJMsK3SB27cXUgSVH6IsUVyoDErFZLUCvhlhWWA7UV3O4PQ 6AQTghfZTYmjjZ44vVA7F/vcxg== X-Google-Smtp-Source: ABhQp+R6XnTEKS8QitI5XMbxBKC+2iTfAj8Z9sHKOtjTQlfFwuoXqNXFJmN8Jg/WFXqbMDCyuykPXw== X-Received: by 10.99.96.87 with SMTP id u84mr672443pgb.424.1510106101512; Tue, 07 Nov 2017 17:55:01 -0800 (PST) Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id k2sm4536847pff.126.2017.11.07.17.54.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 17:55:00 -0800 (PST) To: iasa20@ietf.org References: <150826730924.11473.15624020870916138544@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <2de8f0bd-6009-1375-c60d-4921a77e4d18@gmail.com> Date: Wed, 8 Nov 2017 14:55:00 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <150826730924.11473.15624020870916138544@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Iasa20] I-D Action: draft-haberman-iasa20dt-recs-01.txt X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 01:55:07 -0000 Hi, Thanks for the work on this version. I find it much improved; my comments on the text follow. I'll send a separate message on my overall opinion. > 3.1.3. Authority ... > For example, due to IETF's lack of legal status, contractual > agreements must be signed by ISOC on behalf of the IETF. There are > occasions when a decision that is right for the IETF and desired by > IETF leadership cannot be executed due to constraints posed by what > ISOC can and cannot agree to itself. For example, when IETF sought > to acquire a recent piece of software for business purposes, ISOC > would initially not agree to entering into an agreement with the > software provider. Without asking for details, can somebody explain that a bit more? Was it due to legal or financial doubts, or was there something else going on? > 3.1.4. Oversight All the points in this section are valid, but I think an important issue is still missing: it doesn't capture the conflict of interest when overseers (members of the IAOC) are also volunteer workers for the IASA. I believe that conflict is real and has caused confusion and failures of oversight in the past. > 3.2.1. Volunteers ... > IETFAdminOrg must rely less on volunteers or be better assured of > engagement of willing and capable volunteers. I think this needs to be more explicit, e.g. IETFAdminOrg must rely less on volunteers or be better assured of engagement and formal commitments of willing and capable volunteers. I believe somebody mentioned a while back that other professional bodies get their volunteers to sign a formal agreement. That may not be IETF-style but there's nothing worse than a vanishing volunteer... > 3.3. Lack of Transparency ... > Work to increase transparency has made progress, but we must continue > to address and improve this. At the same time, a balance must be > struck to reach the right level of transparency, so that certain > aspects of contracts, business terms, and negotiations can remain > confidential, according to legal and business practice norms. That's good but I would add a final argument to the last sentence: , and to preserve IASA's negotiating position. There's nothing worse in negotiation than giving away your bottom line in advance. > 4. Goals ... > o Clarify Overall Roles and Responsibilities: Ensure that all staff, > contractor, and volunteer roles are clearly documented. Yes, but the list should *star*t with oversight roles. > 5.1. Overall Structure > > 5.1.1. IASA++ All the points are valid but I think a few are missing: o Precise definitions of terms and conditions for volunteers o Separate IAOC and Trust memberships o Improve NomCom criteria accordingly (These points really apply to all three models, of course.) > 5.5. Staff Structure ... > o Executive Director. The person in this role is in charge of the > overall IASA effort, but can rely on other staff members below as > well as contractors. The Executive Director is accountable to the > Board. Since this applies to all three models, it should say The Executive Director is accountable to the IAOC or Board. ... > Note: The Executive Director likely needs to be a full-time employee, > as is likely the case for the other Director-level positions. I object pretty strongly to the notion that we need a full time Director of Communications. In fact I don't understand why it would be designated as a Directorship at all. A fulltime webmaster, perhaps. But we aren't in the communications business, except as an adjunct to fund-raising. > 6.1. Comparison to Goals ... > In IASA++, leaving the responsibility for sponsorship fundraising > up to ISOC, as BCP 101 does, means we will always be constrained > by however ISOC is willing to staff and support IETF-specific > fundraising. But as I understand the IASA++ proposal, that is not proposed, except that the Director of Fundraising would be an ISOC employee. So this is an unfair characterisation of the IASA++ model. ...> In the IASA++ option, there is limited improvement on clarity of > the financial arrangements. Again, unfair. Whether the financial arrangements are clear is 100% dependent on the clarity of accounting. Once we correct the error of ISOC staff working for the IETF without their time being paid by the IETF budget, this problem goes away in all three models. ... > However, in IASA++, some of lack of clarity may remain, as lack of > clarity inherent in two organizations controlling resources may > remain. Again, unfair. If we do it right - charge staff time to the IETF budget - there will be no issue. We also need to clarify volunteer commitments, of course, but that goes for all three models too. ... > o Improve Transparency: ... > ... The IAOC and committees have been operating with > their current structure, and, in some cases, current volunteers/ > personnel, for a long time. It will be harder for them to change > than to make staff-driven changes in an org with new staff. There's some truth in that, but with a new broom (a new Director) in place, clarification of volunteer roles, and some very clear direction from the community to the IAOC, I don't see it as insurmountable. Regards Brian Carpenter From nobody Tue Nov 7 18:09:20 2017 Return-Path: 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 7857E12AF6E for ; Tue, 7 Nov 2017 18:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cvSnjLFo6ZtI for ; Tue, 7 Nov 2017 18:09:17 -0800 (PST) Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCECB12EB23 for ; Tue, 7 Nov 2017 18:09:16 -0800 (PST) Received: by mail-pl0-x22c.google.com with SMTP id z41so289219plh.9 for ; Tue, 07 Nov 2017 18:09:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=yc3MxtDpQlNSW+/rXiaXiS8XYi2Gsay1GrKFiEUzUtk=; b=bHSCBG+1zJf5HspfPE23cq3qgl/qMGNhzPdrqYYC70NsVQaXPOLdsA02Foieb+5e8a Gw0BNziKYWDQjeUJX65j4AoxnXZyMzstQC0CZT7HrHHHXgIEaqAP++3kHxM7GvBg2NVz ohMaha5dnMp1UiXBofidL98vDVlcteZFVyxvSMiOknOz2qqL3uTn65TSKzsyKPraIIdB 1tr8pobiooDHPL3AJI7XvDxzZbMyvqMnGBq3OmzeUsdrMj6gJ43z7liWpLCrrnVJvZn2 dmzANP071u22SKUv+SCIKZ8KSH7DdZU3aFDRNyb+OfZReXuzMmji3Cv117lG2ljrsYFy PN/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=yc3MxtDpQlNSW+/rXiaXiS8XYi2Gsay1GrKFiEUzUtk=; b=D7TjsAb0MDjfMK72fI5GJfHvn+i0j2SWs6jr9BUAD2GVodL2kXGNAa8yaL3OTlGSCN OovJljExshcjmsCK2QsLKv7JWVhZcmg8I41EOKHqA5kb1FR3gQAUuR4Zq1JW3ZENVZ6U ogOoVDfbDylTDIebL59Q1w5n1i4Q1/q/U9Azd+hhrhP2p3RPS/TrZ8KPM48uZMw0MLdw dXrolIXEj23QewiW4W1PqAvVXUR9pXFofEwgwdtQQg8vwSupmo2EJTosnRY2Kkd/zHiq NZ05l2CXkEDkh74JuglXs5kV7DLFn8sEAIzNNO9uq6c9aP/GcCxVdvE3V8NSSfB3+4Ke nYww== X-Gm-Message-State: AJaThX4vvNt/M69m/tnsNTGbbFczAhN46XDfgWfVcszhkJVL0Mq38A/L Wa3AMoRXIiKdoJalQfSI7SoPpg== X-Google-Smtp-Source: ABhQp+SNhnyk9O8rH6/AIXo7MarKsLpJia1CvljPHVTOElnh1mGjvaO7k318KX/+hI7NgsTYfPfnRw== X-Received: by 10.159.198.140 with SMTP id g12mr697128plo.34.1510106955984; Tue, 07 Nov 2017 18:09:15 -0800 (PST) Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id u7sm4342411pfh.142.2017.11.07.18.09.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 18:09:14 -0800 (PST) To: iasa20@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: <11f08b34-81b3-48b8-30e3-5484376abc73@gmail.com> Date: Wed, 8 Nov 2017 15:09:15 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Iasa20] The three options X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 02:09:18 -0000 I have to say that the new draft hasn't changed my opinion about what we should do. 1) I think that the overheads, the bureaucracy and the risks of creating a new independent legal entity are out of all proportion to the gains. And it would not reduce our financial dependence on ISOC by one kopek. On the contrary, it would in the long run reduce ISOC's motivation to support the IETF. (One of the several mechanisms behind that is that with an extra Board to staff, we'd have fewer IETF folk willing to serve on the ISOC Board, so over time they would hear less from us and therefore see less reason to feed us.) Also, after ten years or so, the IETF would be complaining at the lack of transparency in the new organization, its failure to listen, and its stupid choice of venue for IETF 135. 2) I could live with an ISOC subsidiary. But it's only a fancy way of separating the accounts, so I don't really see what we gain. What we pay is a bit more bureaucracy. 3) So I think that IASA++, *done properly*, is the least costly and least risky option. I hope my comments on the draft indicate what I mean by 'properly'. Now I'll go and read other opinions, which I've carefully avoided so far. Regards Brian From nobody Tue Nov 7 18:52:35 2017 Return-Path: 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 7B76112EB25 for ; Tue, 7 Nov 2017 18:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 n8lOQDozn-4S for ; Tue, 7 Nov 2017 18:52:31 -0800 (PST) Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A39129468 for ; Tue, 7 Nov 2017 18:52:31 -0800 (PST) Received: by mail-pl0-x22d.google.com with SMTP id g16so355541plj.1 for ; Tue, 07 Nov 2017 18:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=uiaip9NYpcSs4anTf+pNAFfxBtuThGOQbEmSWnzjd7U=; b=oVbCkl8bKlvAmaZ/gjMBMMJf9doI7jaT6fXGZ7QXvkoQBXzxKBq2U5r+8TIKGdmEP+ xilnJywSrrVkvX54HnJNHWGfu9gmntddlTgSDSuOAycfTeEMMB5flMSDLESm9Kgc/fV/ prmGZNDSf8Oa+0uOqzpZrKBKYiX7ltEoou8KKO61iz39RLeRRePRET1Xd+yE5ucajns8 f2Fzv1o5kYrDOzNdIaknxvMjUwpz94KtxT9UJeAkNMzgLCx6OS7DPmMRAVvrTJyF9051 0QT/DRT532sPITrVb+DPOOP9iRLYWG8aMwcjIxHhH7nT2FxO605tn+0hFnCHMvlpQfZh rU3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=uiaip9NYpcSs4anTf+pNAFfxBtuThGOQbEmSWnzjd7U=; b=f3NHw0xOfNwTtapW7HFP87fINX++VuqgPP8sahSp0Y5sf1oAh/LZ2uI2PWiOD1zjbQ 7Vt0Ye81NsobtVOuR9b3keRWyTO3VskoVMOQ3U43WkItxT+hemFmF1JtIRvud3BEv9jt 9oqQLEumj5CqCD1wnIaNkuyScM9ZcgDHvP4Oj8UE1CgNfY/T8z82+WC6kKr/dZXIp7Qs DBAlfOWTfh0zjHQ4IAMm2atFNHpFE1zqG50e0eKn6CnsHbPX+SNOK99y7bUVN9hZBqEK LLoeSrptBrvKMZ18VnYiwpxgv2gyAaEYyX4mgPZ+aGq/xkLNupjOodIWJsCyQA6UhHB/ rBhw== X-Gm-Message-State: AJaThX4jsGwhFoCPTKvX+BJ4AIkZ2bygC3SCNIVn8UQVA5rKwoeGqlhk y9Kb3LcHG9CyR56kAPxvCSFPww== X-Google-Smtp-Source: ABhQp+RUquZyGI+D1PHYfuiU8TOzINFAXRDnoIJ7X7qME2+RL0sqq9oVTom7gZhGhvrazZu8S4hmQA== X-Received: by 10.84.210.66 with SMTP id z60mr796637plh.168.1510109550934; Tue, 07 Nov 2017 18:52:30 -0800 (PST) Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z127sm4921943pfb.63.2017.11.07.18.52.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 18:52:29 -0800 (PST) To: Richard Barnes , iasa20@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <0678aa86-82fc-1484-8a8c-4df313cfe689@gmail.com> Date: Wed, 8 Nov 2017 15:52:31 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Iasa20] Review of draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 02:52:33 -0000 On 19/10/2017 06:55, Richard Barnes wrote: ...> * I don't see much point to IASA++. Given the degree to which this exercise > is focused on increasing clarity and transparency, it seems worth having a > clear organizational boundary and an entity that is clearly accountable to > IETF. If you were to try to meet the clarity and transparency goals while > keeping the activities within ISOC, you would end up effectively creating a > subsidiary anyway, but without the benefit of the clear rules around an > actual subsidiary. In other words, IASA++ is just an inferior version of > the Subsidiary case. Disagree. Of course the devil is in the implementation details, but I would reverse your assessment: if we do IASA++ right, the subsidiary is an inferior version of IASA++ (more bureaucracy with no practical effect). > * I don't really see a lot of difference between the subsidiary and independent > cases as long as ISOC remains a predominant funding source for the IETF. That's exactly the point. Apart from even more bureaucracy than the subsidiary, it would weaken the relationship with ISOC over the long term, and hence jeopardize our main funding source. ... > * Likewise, in either the subsidiary or independent cases, there will be a need > for an explicit contract / MoU with regard to funding. We need that in the IASA++ case too. Its absence is one of the reasons we have complaints at the moment about lack of clarity. Indeed, that's why it's important that all staff time is charged to the IETF budget, and that all volunteer effort is documented. And why it's important that the IAOC does oversight rather than execution. I think we have a choice. Fix things that aren't working, or add one or two layers of bureaucracy and hope that they fix themselves. Brian From nobody Wed Nov 8 10:13:49 2017 Return-Path: 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 21DB61294F7 for ; Wed, 8 Nov 2017 10:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 c4ZXYhU0jvHr for ; Wed, 8 Nov 2017 10:13:46 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C0E1294C4 for ; Wed, 8 Nov 2017 10:13:46 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id j2so2331970vki.4 for ; Wed, 08 Nov 2017 10:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JyiJL8xH5phbtgVNlbjBZS3hCliZM0rxll/odJfkOmk=; b=B5VBcCIBRvg+o1M8nXcqokwD1HHGy3TRQSV2c28MT//vVA6+U2O6M/TuMKqOV0bX93 34dczhDa9i1UXhR+4EWqWmZNIYfMuwkzkZpzTCxoMny86CoFC6Rsq5vC8HTlJG19xK56 1BnNCY+5P+J5WeGLU/N2fkSE49rM/PZg1TCGo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JyiJL8xH5phbtgVNlbjBZS3hCliZM0rxll/odJfkOmk=; b=NAxs1B5rmHu0s9auqiPMrGNWmVo39H7iQiXVvgqGkXFL8ncatWXSHvfxlEW/RMHOHt qc4HKOaeGFmVXEQwRRJIB6BtybV93PWqiILGa7uH5qb9XNerN0guYhjCI+PJH3Nv83Le sIRM11s/b1K9XCnBYGm+TeR64BriYeFQUS5Un04jaM0KfVPObP+Gu92hhqMlvB6OqAec 7fdHsa+ReG0Su0RVzSLbUXH1c4R8fL623Lvt+Yxsqeyi7IJo+oksTnWuELVf5nhlUVdI ebzqrm4d6gXj5k501yd9YMY5OaT3JazbHOIwpyJAmsibu8iPnuu5GzEHgiyEqIg9yTKe 1ICA== X-Gm-Message-State: AJaThX6iUvmzNfM+LGZGYySyeChMafH2LRmHYhBNYoPrfbA2kind0gx0 7+DKIQAGNpZ922QfGEwdF743djULk3pBG011i2iZWw== X-Google-Smtp-Source: ABhQp+S8MfCiFkCbHJBQ9d91ar/ZYXnAh6jhpCNLVaZwNG/dI9Do4GT70+ulySVEovqUpoxrrAil1xC8V5amCDKPLSY= X-Received: by 10.31.151.21 with SMTP id z21mr1123997vkd.44.1510164825316; Wed, 08 Nov 2017 10:13:45 -0800 (PST) MIME-Version: 1.0 References: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> In-Reply-To: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> From: Joseph Lorenzo Hall Date: Wed, 08 Nov 2017 18:13:34 +0000 Message-ID: To: Jari Arkko , Matthew Ford Cc: iasa20@ietf.org Content-Type: multipart/alternative; boundary="001a1140e866f73d1c055d7ca53c" Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 18:13:48 -0000 --001a1140e866f73d1c055d7ca53c Content-Type: text/plain; charset="UTF-8" > MDF: Except that it would, for the reasons you articulate below. To be more constructive, given the constraints below, how would the independent org option differ in practice from subsidiary option? Would it be an explicit goal of an independent org to develop fundraising to the point where ISOC support was not required? Of course, in the subsidiary model, although its own legal entity, the parent entity (ISOC) could literally tell IETForg what to do. I'm not saying they would, nor that the subsidiary agreement wouldn't carefully define that, but the would be no formal control possible in the independent model. I may easily have overlooked something, but that's a major difference in my opinion. Best, Joe -- Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --001a1140e866f73d1c055d7ca53c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> MDF: Except that it would, for the reasons you artic= ulate below. To be more constructive, given the constraints below, how woul= d the independent org option differ in practice from subsidiary option? Wou= ld it be an explicit goal of an independent org to develop fundraising to t= he point where ISOC support was not required?

Of course, in the subsidiary model, although its own = legal entity, the parent entity (ISOC) could literally tell IETForg what to= do. I'm not saying they would, nor that the subsidiary agreement would= n't carefully define that, but the would be no formal control =C2=A0pos= sible in the independent model.

I may easily have overlooked something, but that's a major di= fference in my opinion.

= Best, Joe

--
Joseph Lorenzo Hall
Chief Techno= logist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3= 497
e: joe@cdt.org, p: 202.407.8825, = pgp: https://josephhall.org/gpg-= key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10=C2=A0 1607 5F86 6987 40A9 = A871
--001a1140e866f73d1c055d7ca53c-- From nobody Wed Nov 8 11:47:37 2017 Return-Path: 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 7005E124D37 for ; Wed, 8 Nov 2017 11:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 REh_TxX30oGF for ; Wed, 8 Nov 2017 11:47:34 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBD75126DFF for ; Wed, 8 Nov 2017 11:47:33 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id s2so2699988pge.10 for ; Wed, 08 Nov 2017 11:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KHRESNhkNo44JUCUFdShTyAuKhep+Fb412wvMyIZuM8=; b=qndd65yCeLAr6gaITZq5lA8/6IjEpAsGPsl5cA5ptrCGPlbUrWEaff45kXkBN0xz1/ lMGqx8ObG1e/jBW+kPM69cX0DoowrwynAu4WWyyN7jatwyNbBztoGN6DWW1jbxWv6zWP nJQJ+Bn04aPw1bXUQ9wMnA1KxBeQzB2rBxuzn52fok2CPrizrmYu3z5d74RaU34cay0k MrIb22F4IkZUImrbMa2IlZAe2WZgrXQ0ONt/Ie3n1zRXM93mcCVxrvuxVyyJZYU+8e1U HFQC6WngCSDa3FJx6sobgKRTYFc8ECgacgxUNEbpLUf4clWekXYUeKYBbwUHTZ//ah4q b8zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KHRESNhkNo44JUCUFdShTyAuKhep+Fb412wvMyIZuM8=; b=YbNDpv3VydWnfy5oIGyDfsEkmCvGp94YykeMeV1rpQ1Dk0IDnQ3M3alztA8Ni2yuFl 8EN9ho53JnlAY17w6nps5DnxPF6BZJLU7OrHaU/J1lQyzUfne/GOxcZSg8cdU/m5Sb3v jq4odecjGPG69q4JYreGYwgHggDIVvY0UXbAj0TYINEZBM1pcLWZR9SvkzPrCYuDwKqk +pSpUP88vwmc3UoxBLSYs02h5e2merHcSvtZH5gWVqVNlwJ2QxHAQR0glFIqyN1X0M6i gn9XBJsvfI0S6HJCp6sMCeouaROrTY1GS0yKfoyNDxb1PhNmDQE/lLbtMyiF1Cs1g/ma XYBQ== X-Gm-Message-State: AJaThX6SLziJZYHd4UPSjTlkLNZk1hqTuj1f+DFPyyc1QbKjhkPA3jFN PzZVPlpAeVmZLrggIjlGMgI= X-Google-Smtp-Source: ABhQp+RzKOtuM330gYTvpoEx06WyLl/wKkQF+4a855dCysQ/V0+mfnvuQDiiNCFXiXI0H6SEuPJ1aw== X-Received: by 10.84.209.164 with SMTP id y33mr1396329plh.439.1510170453453; Wed, 08 Nov 2017 11:47:33 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id i129sm8180733pgd.21.2017.11.08.11.47.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 11:47:32 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9982DCE0-0A5B-435F-AA77-7A3E5129371C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 8 Nov 2017 11:47:30 -0800 In-Reply-To: Cc: Bob Hinden , Jari Arkko , Matthew Ford , iasa20@ietf.org To: Joseph Lorenzo Hall References: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 19:47:35 -0000 --Apple-Mail=_9982DCE0-0A5B-435F-AA77-7A3E5129371C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Joseph, > On Nov 8, 2017, at 10:13 AM, Joseph Lorenzo Hall wrote: >=20 > > MDF: Except that it would, for the reasons you articulate below. To = be more constructive, given the constraints below, how would the = independent org option differ in practice from subsidiary option? Would = it be an explicit goal of an independent org to develop fundraising to = the point where ISOC support was not required? >=20 > Of course, in the subsidiary model, although its own legal entity, the = parent entity (ISOC) could literally tell IETForg what to do. I'm not = saying they would, nor that the subsidiary agreement wouldn't carefully = define that, but the would be no formal control possible in the = independent model. >=20 > I may easily have overlooked something, but that's a major difference = in my opinion. If the IETF continues to be dependent on generous funding from ISOC, = then ISOC would continue to have control one way or another. The = independent model isn=E2=80=99t independent if it still depends on ISOC = funding. Bob --Apple-Mail=_9982DCE0-0A5B-435F-AA77-7A3E5129371C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloDX1IACgkQrut0EXfn u6iDSAf+N3ywq9uQEtijaXBHI3mnDy20z8JgN0jUHzb1TIoaA4vOGbWa3PkbpS4a RbIupyfTSo6aNUSXisiwFayTAgYyrmaJrOZF1a7t/tq2RBhpZH+24g4i3ymUUwp0 4j2aRdI0MDpnLczkyHLcWs0mDO8893sgKBtPJGx8LtXtAuwBIaYs73LyAsgU0LSO ZMOwR7NLbVAvzHSe1J5wbgKvA6klDAIdO45OyxA/Am63rNgScV4PkdD+jsXUnJEU TmIyMlqi2THcTqQdQoRd6V/jb8zEMoeigPy2HtTxZIAyxbdZhRvlgvNfEXg9lBVX ket30Ex8obNvF+XDg5ocPKNzPJkmuQ== =ao0e -----END PGP SIGNATURE----- --Apple-Mail=_9982DCE0-0A5B-435F-AA77-7A3E5129371C-- From nobody Wed Nov 8 11:57:11 2017 Return-Path: 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 F31691294EE for ; Wed, 8 Nov 2017 11:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 dD1y_UuLBxYR for ; Wed, 8 Nov 2017 11:57:08 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7970126D3F for ; Wed, 8 Nov 2017 11:57:07 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id k61so3506656wrc.4 for ; Wed, 08 Nov 2017 11:57:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7ftKcWkAXt4Qo7HdJ8UHvVBjKeEMKL8qpmYmgVrk0ZQ=; b=j1stdfwQz4s1cjgPDx1hvfABZufsais7VjhBzb41AGA0toVMOAUDmWqoGVUcejuIsq 7RaLMPPVml/jV53jP2nTfOz+2P5McZY/p0TJgqmxGrbcQPEV4/FH3Whp7w6vycyobjxR uIHf7o9oBeGEZ7Gka6hzuxo29GjJjrAcMxVljUn7IYCNN25fNcy/EdLppuBjAs1RFc33 H7L04/y4zHHTc6U8wH8nzrajyULhe63/DcZglzKiLjzZL1iLOfBWmwU9taacsxSI6ULC gfABwLjiqsbCUTnCiIENFcQDxo4yIW6w0T/V7GkNfQM/iJwHtresVAgsAUukxND7yoMb n2tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7ftKcWkAXt4Qo7HdJ8UHvVBjKeEMKL8qpmYmgVrk0ZQ=; b=aP583sfJMplte4UD4GRglUkO3hstoibBu/ukhDDtc4lOD/yjJ+ckphS1PYsRXW7s0m dop6CQhw1byPGTWvq1uh4+rN1SE5NSSsLRfWw68g0DtpjjoI7IM53NZ/qOViY4DesRut NUY2Lkh+0MsqSI59A0Uja7y+t9LWAr31IezJ8tyz1nq6F1YMNQGxNY/P3Q3v9XHGPrLy JWZgADHvurYlIjC+5Dg+2uda/BT/rveshQpqQaEuHKbyYdxy2m4gjcGY4BEz+aHGlvDx CrlHIZ9FaYjLnkCuyDWMVUoPTha32O1hijXFOFsqnKXbWGwiQH2NkxI9MO2GkkhanJua 1Abw== X-Gm-Message-State: AJaThX6Zf+Jv6HSvaWL4dwBNEDUmJf/S8Rhk/ZtEP7CNVHbqRj1AP9XF VMTWu6a14lSh5ZWXJ5y1f0vWrk/WIzcD8Md7adxy9Q== X-Google-Smtp-Source: ABhQp+RKm7K0aSDKw44tJwKWiSKPK65HA3gSota+tIVMcom/P+YQNTCuEkPytJA5u/9VzqM4kwHPF+y92bSg6Y7c/A0= X-Received: by 10.223.152.16 with SMTP id v16mr1346088wrb.108.1510171026179; Wed, 08 Nov 2017 11:57:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Wed, 8 Nov 2017 11:57:05 -0800 (PST) In-Reply-To: References: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> From: Richard Barnes Date: Wed, 8 Nov 2017 14:57:05 -0500 Message-ID: To: Bob Hinden Cc: Joseph Lorenzo Hall , Jari Arkko , iasa20@ietf.org, Matthew Ford Content-Type: multipart/alternative; boundary="f403045d55a690db1e055d7e173e" Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 19:57:10 -0000 --f403045d55a690db1e055d7e173e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 8, 2017 at 2:47 PM, Bob Hinden wrote: > Joseph, > > > On Nov 8, 2017, at 10:13 AM, Joseph Lorenzo Hall wrote: > > > > > MDF: Except that it would, for the reasons you articulate below. To b= e > more constructive, given the constraints below, how would the independent > org option differ in practice from subsidiary option? Would it be an > explicit goal of an independent org to develop fundraising to the point > where ISOC support was not required? > > > > Of course, in the subsidiary model, although its own legal entity, the > parent entity (ISOC) could literally tell IETForg what to do. I'm not > saying they would, nor that the subsidiary agreement wouldn't carefully > define that, but the would be no formal control possible in the > independent model. > > > > I may easily have overlooked something, but that's a major difference i= n > my opinion. > > If the IETF continues to be dependent on generous funding from ISOC, then > ISOC would continue to have control one way or another. The independent > model isn=E2=80=99t independent if it still depends on ISOC funding. > This is like the "no point to encrypting SNI as long as we send DNS requests in the clear" argument. What you say is of course true, but myopic. If the goal here is to allow the IETF community to have more autonomy, and there are two barriers to that, you're going to have to remove one of those barriers first. Just because there are two doesn't mean there's no point to removing one. And between the two you've noted, removing the organizational lines of control seems like the right one to go first, since it is less disruptive and sets the stage for addressing the second, e.g., via fund-raising under direct IETF control. --Richard > > Bob > > > > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 > > --f403045d55a690db1e055d7e173e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 8, 2017 at 2:47 PM, Bob Hinden <bob.hinden@gmail.com> wrote:
Joseph,

> On Nov 8, 2017, at 10:13 AM, Joseph Lorenzo Hall <
joe@cdt.org> wrote:
>
> > MDF: Except that it would, for the reasons you articulate below. = To be more constructive, given the constraints below, how would the indepen= dent org option differ in practice from subsidiary option? Would it be an e= xplicit goal of an independent org to develop fundraising to the point wher= e ISOC support was not required?
>
> Of course, in the subsidiary model, although its own legal entity, the= parent entity (ISOC) could literally tell IETForg what to do. I'm not = saying they would, nor that the subsidiary agreement wouldn't carefully= define that, but the would be no formal control=C2=A0 possible in the inde= pendent model.
>
> I may easily have overlooked something, but that's a major differe= nce in my opinion.

If the IETF continues to be dependent on generous funding from ISOC,= then ISOC would continue to have control one way or another.=C2=A0 The ind= ependent model isn=E2=80=99t independent if it still depends on ISOC fundin= g.

This is like the "no point to e= ncrypting SNI as long as we send DNS requests in the clear" argument.= =C2=A0 What you say is of course true, but myopic.=C2=A0 If the goal here i= s to allow the IETF community to have more autonomy, and there are two barr= iers to that, you're going to have to remove one of those barriers firs= t.=C2=A0 Just because there are two doesn't mean there's no point t= o removing one.

And between the two you've not= ed, removing the organizational lines of control seems like the right one t= o go first, since it is less disruptive and sets the stage for addressing t= he second, e.g., via fund-raising under direct IETF control.
=
--Richard

=C2=A0

Bob



_______________________________________________
iasa20 mailing list
iasa20@ietf.org
https://www.ietf.org/mailman/listinfo/iasa20

--f403045d55a690db1e055d7e173e-- From nobody Wed Nov 8 13:27:56 2017 Return-Path: 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 08C84124B0A for ; Wed, 8 Nov 2017 13:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6Q567yZI8CXp for ; Wed, 8 Nov 2017 13:27:52 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7541E124BFA for ; Wed, 8 Nov 2017 13:27:52 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id s2so2913173pge.10 for ; Wed, 08 Nov 2017 13:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/Q6JBvySbgTJBDdagCwogXYKCbN8WUp0BJMqoxfeO7E=; b=Y3b2exODTX6S3Fc2NT/1+AArAnXiWn43vTQqbGOiroK/70PCpOiE5bCJygPM6lyIai HnfO5ikSSMf3DKS8zA7FCEaOvE8HGnuDkEOTpuazlH/CmpkuvBxLha3s0k9nZUNoQ5gU BSe3Xw/LG4a/cevcEGChLLCoAha2SwzrVdu7eNOeEvPa+IDSNPdDkQIXjnALJc/tYvi0 DMTwsqAzaPhQzNrqVdtUTja710X504XFL79nY3ZzyIeabjY6UZmFJGIC9kElXC73V67/ Tr+2+CypEWQ6NqqbgQMBltt58pmJhzNcuvJE7dIfF/H71fxmSBkKq5q8CpTZ0rk6fMJ6 7S+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/Q6JBvySbgTJBDdagCwogXYKCbN8WUp0BJMqoxfeO7E=; b=kGpKDh6lmgxpwLecCrSeN/7oLqo4HOjHHb+DBA6kts81KJXeJUt/57U21Xzt7A6fKN oW7OgXt1XMvpokH2F2bVoIymaUCP2OmdKIo5ojchuf7nrrqV8KZ5G5EG+ayFo9wN5d4y pNqv2FFMqgqo4f3qmj5yyD2616ffUImbg98FKK5sPOuMQA6cnUGcmDsFlYSIBYSm5FQi 6IbVWuv09F0oWB6Zj8n/6If9rNV5aa1QRaASQaprm4OCigbLuZVbbPcGC/R7rLgFhne7 lkQ2cp0FkUFRL566paxKe26ajSfSm6hnUof5W6AmNVDvCmGtugO9vdcldI1Af7mx/GPR aT1Q== X-Gm-Message-State: AJaThX7ajFcI5rFHMfDC6Lt+UwnhpLJiUwqc9xCPyAhoWNzPeBfznJqI hVw8IeIzPajl2Vtb4cOpDG4= X-Google-Smtp-Source: ABhQp+Rw6NcHXrhOEOl4uK9m0F7iO2TgmOTcLYAlhTbUDNTpHAebdm49EOpEfH6qRQdzycEySNYNZw== X-Received: by 10.159.254.12 with SMTP id r12mr1646605pls.49.1510176471925; Wed, 08 Nov 2017 13:27:51 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id 9sm7732418pgg.42.2017.11.08.13.27.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 13:27:50 -0800 (PST) From: Bob Hinden Message-Id: <6B399B19-037A-4F59-A35C-73FEF074F7C1@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_35A37729-9E4C-491F-AD2A-7F897C60A256"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 8 Nov 2017 13:27:49 -0800 In-Reply-To: Cc: Bob Hinden , Joseph Lorenzo Hall , Jari Arkko , iasa20@ietf.org, Matthew Ford To: Richard Barnes References: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 21:27:54 -0000 --Apple-Mail=_35A37729-9E4C-491F-AD2A-7F897C60A256 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Richard, > On Nov 8, 2017, at 11:57 AM, Richard Barnes wrote: >=20 >=20 >=20 > On Wed, Nov 8, 2017 at 2:47 PM, Bob Hinden = wrote: > Joseph, >=20 > > On Nov 8, 2017, at 10:13 AM, Joseph Lorenzo Hall = wrote: > > > > > MDF: Except that it would, for the reasons you articulate below. = To be more constructive, given the constraints below, how would the = independent org option differ in practice from subsidiary option? Would = it be an explicit goal of an independent org to develop fundraising to = the point where ISOC support was not required? > > > > Of course, in the subsidiary model, although its own legal entity, = the parent entity (ISOC) could literally tell IETForg what to do. I'm = not saying they would, nor that the subsidiary agreement wouldn't = carefully define that, but the would be no formal control possible in = the independent model. > > > > I may easily have overlooked something, but that's a major = difference in my opinion. >=20 > If the IETF continues to be dependent on generous funding from ISOC, = then ISOC would continue to have control one way or another. The = independent model isn=E2=80=99t independent if it still depends on ISOC = funding. >=20 > This is like the "no point to encrypting SNI as long as we send DNS = requests in the clear" argument. What you say is of course true, but = myopic. If the goal here is to allow the IETF community to have more = autonomy, and there are two barriers to that, you're going to have to = remove one of those barriers first. Just because there are two doesn't = mean there's no point to removing one. >=20 > And between the two you've noted, removing the organizational lines of = control seems like the right one to go first, since it is less = disruptive and sets the stage for addressing the second, e.g., via = fund-raising under direct IETF control. >=20 I don=E2=80=99t see why we have to reorganize to fund raise. I think our fund raising difficulties have little to do with how we are = organized. It appears to me to be industry changes where potential = donors don=E2=80=99t find enough value in what the IETF is doing. This = isn=E2=80=99t going to be fixed by creating an =E2=80=9Cindependent=E2=80=9D= organization. Bob --Apple-Mail=_35A37729-9E4C-491F-AD2A-7F897C60A256 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloDdtUACgkQrut0EXfn u6ipSgf/aHPV8fc4S1/S6XGJZY65MCDbrjYaMZa46tebPLSWl+a5F+1k0/c3I2C0 falmLDJrS22NmLw0a4qwRNoTeMcZj0jMn1cKn2UxeQGFtKpxwxazb9US97H0Wx68 nzTw3fkWTsADVcZIWcLhNl0tH9IH1bbJMGT/IXmYazjwoHrgsonNecbVbFUIGxRW +Ti+IRWPtv8gbXYrGfsI+qnM5G94GtGGW3Ol19kF1InqNOhd1rtnz4c1EajyPe17 4CDdkXxWUiE3JdDqWXOoX5ysmoknDf6H7zUftP7vMDi8ERjgvV3TfMSvy0oscAqh xMVTusxjWYWmcTVf+35c/jhFJvmfQQ== =MvfV -----END PGP SIGNATURE----- --Apple-Mail=_35A37729-9E4C-491F-AD2A-7F897C60A256-- From nobody Wed Nov 8 13:40:50 2017 Return-Path: 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 5CAFF126D85 for ; Wed, 8 Nov 2017 13:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Z42/VYEc; dkim=pass (1024-bit key) header.d=yitter.info header.b=iKU8nDRC 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 xUehnjYUhomQ for ; Wed, 8 Nov 2017 13:40:45 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0EE1252BA for ; Wed, 8 Nov 2017 13:40:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id C96D4BF56B for ; Wed, 8 Nov 2017 21:40:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510177214; bh=OTm6PtwDSEIM3Ok0uZo3GKQEifw/8nATmcT8X5Qunss=; h=Date:From:To:Subject:From; b=Z42/VYEcgD64tf9T/Uhqt5knicfX0nIdoA3VwRRJyqtlrdP/jqj7bpfcc1UDdkLqq 8uikfQwhMU9vfcO5tv/wLzywiYt4mDwiUOdqrkqPe5TDA12CWafZmBlG/AOV3nwtbi 27RWZxoycyYBUssbYUjgn3AXrMzvuvVIm9SuUnsY= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxDCoszufeLo for ; Wed, 8 Nov 2017 21:40:12 +0000 (UTC) Date: Wed, 8 Nov 2017 16:40:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510177212; bh=OTm6PtwDSEIM3Ok0uZo3GKQEifw/8nATmcT8X5Qunss=; h=Date:From:To:Subject:From; b=iKU8nDRCqPOdKLd2cne67sOP4T7atQ4rn6KYo6BY4nOQOftkf7dkjkimxovjxpL57 rzA9+qL2q2tuPWhgi50FqIDy3h6X8No/BU3cmUV36nYggBtOO6B4dBFpXBylRyzMi1 FeRuxQU/h+mw5z4FBmuW07stmJ4lREFUSQkpmtTQ= From: Andrew Sullivan To: iasa20@ietf.org Message-ID: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Archived-At: Subject: [Iasa20] Some comments on draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 21:40:48 -0000 Dear colleagues, I have read draft-haberman-iasa20dt-recs-01. I have some comments. These focus mainly on the "three alternatives" questions for now, mostly because that seems to be the most pressing set of questions. TL;DR: I do not think that IASA++ delivers what we need, and I don't think it's good for ISOC either. Given the ways in which the IETF and ISOC have both grown, it is not obvious to me that the historic close link is one that needs to be maintained, and the cleanest approach would obviously be to set up a new separate organization. For practical reasons (including the lack of obvious organizational expertise and the reality of available funds for the IETF), I don't think that is a good idea, and so I am left with the subsidiary organization choice by default. Finally, I think that in tackling all of this there remain some internal IETF-only organizational knots that have never been unwound, and I think they need to be as well. Supporting arguments below. 5.1.1 describes IASA++. There is a critical sentence in that subsection that describes a central issue: "The IETF needs to be able to make its own administrative decisions independent of ISOC." If we take this to be true, then IASA++ is simply not an option. As the draft illustrates, the present IASA structure (and therefore any IASA++ approach) has the automatic problem that, structurally, the IETF simply cannot possibly be in control of what it is doing. This is not to cast aspersions on the good work, positive effects, or correct intentions of anyone who has been involved in IASA for the past 10 years. But ISOC employees are going to be measured according to ISOC requirements, not those of the IETF. ISOC contractual terms are going to be determined by ISCO requirements, not those of the IETF. And so on. We put both ISOC and the IETF in an awkward position when we try to pretend that one of them doesn't exist and doesn't have independent needs. I am particularly concerned about the staffing issue. The IAOC's current job is oversight of the IAD and under IASA++ it might get more such oversight responsibilities. But the difficulty is that the IAOC is not ultimately able to make the normal decisions a supervisor can: hiring and firing, promotion and pay. For many years the IETF was fortunate to have a dedicated person filling that staff role, but there's nothing guaranteed about that and the resulting chain of responsibility does not meet the community need for transparency -- particularly when IAOC terms may be only two years long. I also don't see how this model serves ISOC well. ISOC has to face its own pressures to evolve, and it has legal and policy imperatives that the IETF (which in this model doesn't have them) will likely fail to comprehend. There may be one advantage of that legal fiction, however, that is worth attending to. Effectively, because the IETF is just "an activity" rather than an organisation of ISOC, the lack of independent legal existence means that legal issues tend to entangle the IETF less directly than they otherwise might. If the above reasoning stands, then it seems obvious that in a perfect world the IETF would set up its own organization and carry on from there. There would be no bar to collaboration with ISOC wherever it was appropriate, and indeed such collaboration could well be more effective than the state of affairs today. (In my experience dealing with "the outside world" as IAB chair during the IANA stewardship changes, way too many conversations ended up in a ditch trying to explain the organizational boundaries. The distinctions might well be plain to us, but they are foreign and strange to others; in the worst cases, our views were dismissed as just another iteration of the same ISOC positions people had already heard. But more on this below.) At the same time, the sometimes awkward ties that exist because of the administrative arrangements could be done away with, freeing both organizations to work in ways that are best for each. But it would be perverse to imagine that the IETF is in any way prepared to undertake that sort of task. First, it's a lot of work, and that's work that we would not spend on pressing technical and architecutral issues also facing the network. (Not to put too fine a point on it, I did not want to spend most of my time on the IAB thinking about the dark corners of inter-organizational theory in the face of some unco-operative community or constituency. That was the straw I drew, but I wouldn't wish it on others.) Second, it requires a realistic and long-term plan for financing the effort, and we are nowhere near a position to do that. Finally, we would need evidence that we have the people required to make it work. I don't think we do: filling the IAOC positions has not been easy for some years now, and several of them are filled automatically by virtue of some stuckee being in another seat. I am therefore persuaded that an ISOC subsidiary would be better. A subsidiary can conclude agreements with the parent organization pretty easily, which means that some of the transition could be undertaken relatively painlessly (by contracting explicitly for services the IETF already gets implictly through its relationship with ISOC). Such an approach allows the two organizations also to formalize a number of the improvements that would be required for IASA++ anyway; and by formalizing them, we get additional transparency into how that part of the relationship works. It also allows the two organizations to develop the policies and procedures necessary for each, thereby permitting continued evolution in appropriate directions. And it sets up clear boundaries of responsibility, so that the next time we need to analyze our administrative arrangements our first problem isn't to pick apart which arrangements are ours and which are someone else's: the definition will be in contracts. The challenges of governance of this new subsidiary remain a problem, but again the appointment of a board gets a certain amount of benefit from being a subsidiary: I'd expect any subsidiary to get some board members appointed directly by the parent, and I should imagine the same would happen here. It's the parent's money, after all. Finally, I think it is important in tackling this work to note that there are some blurry lines entirely under our own control, and if we're going to fix the administrative arrangements we're going to have to clean those up too. Some of these are referred to in draft-daigle-iasa-retrospective-01. In general, I think there is a problem of responsibility and authority between IASA and the IESG (or on a couple issues the IAB), and it would be nice if we made those interfaces a little cleaner while we're in there. (For instance, I can think of at least once where IASA was blamed for meeting imperatives that were not its own creation: IASA gets the responsibility, but it doesn't always have the authority to act independently.) If we are going to set up a corporation with a board, we are not going to be able to allow that to persist without having some nasty fights. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 8 13:47:46 2017 Return-Path: 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 7BBFA126BF7 for ; Wed, 8 Nov 2017 13:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=aQbcVxQR; dkim=pass (1024-bit key) header.d=yitter.info header.b=EFds+dm/ 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 QbE5YkAwKGAc for ; Wed, 8 Nov 2017 13:47:43 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99E8128BA2 for ; Wed, 8 Nov 2017 13:47:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 136D2BF56B for ; Wed, 8 Nov 2017 21:47:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510177631; bh=HvcyTuzg8xLKGrquwnEubxL8ulgu9QakvoSLoFFaDdE=; h=Date:From:To:Subject:References:In-Reply-To:From; b=aQbcVxQRWmhzGtz108hwrKtaf70QlkOcZwIX+uiBCrYNaBSJl0wY/3tW8Cywcr38P NJsdglFEgBHLAN6aLEI7IV2RHHYcFxAV/C0YAZOOqnk1xQeZ8jxgqiXfVLFONTpBjR TobRMQZhx6Wnk2MWB48eloBkmvdpjg9NI8cDg/Ts= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6h2FNVL3_K_3 for ; Wed, 8 Nov 2017 21:47:10 +0000 (UTC) Date: Wed, 8 Nov 2017 16:47:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510177629; bh=HvcyTuzg8xLKGrquwnEubxL8ulgu9QakvoSLoFFaDdE=; h=Date:From:To:Subject:References:In-Reply-To:From; b=EFds+dm/4RF8snZv8YuOERA3qJG38+pMDGspHJ1Bfrc31PvkTCDZN9p6AlFuHD4ns M9HqKl1U8DLag3ZE2RE/G//VMoFgDRIz2GaJPT5Gll+dNS4ABTOV8Q9Jas7Mglkd0b wNONnioaXYvlKODkY6j72bijXQrZ+GPRMg52r4Sk= From: Andrew Sullivan To: iasa20@ietf.org Message-ID: <20171108214708.3twjdffmjhknqarz@mx4.yitter.info> References: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> <6B399B19-037A-4F59-A35C-73FEF074F7C1@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6B399B19-037A-4F59-A35C-73FEF074F7C1@gmail.com> Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 21:47:45 -0000 On Wed, Nov 08, 2017 at 01:27:49PM -0800, Bob Hinden wrote: > I think our fund raising difficulties have little to do with how we are organized. Well, this is just an anecdote, but it matters in at least _some_ cases. I personally made appeals to people whose response was, "Why should I give more money to ISOC?" Our answer today has to be, "Trust us, it's a dedicated fund," because we don't have a different governance organization controlling the money. Now, this might have been because of the people I was talking to, and their peculiar focus at the time on governance issues. But it certainly isn't an objection to which we have an obvious retort. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 8 13:59:52 2017 Return-Path: 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 7904F129400 for ; Wed, 8 Nov 2017 13:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gHurKEw80srv for ; Wed, 8 Nov 2017 13:59:50 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5405E1275FD for ; Wed, 8 Nov 2017 13:59:50 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id a192so2981949pge.9 for ; Wed, 08 Nov 2017 13:59:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SOZ+7B5P7TLqgXOsnD9r+OFaoY8xtrr371vnomrX2+0=; b=i7dluyKMx1GBCECigahuCf0nASEE7tx7IT95/GLNr87LVWuLA7HpHiMDaL9+lsVzPb XlwppJRKNR+5qdRBNBGtFM9ScWyrI6MqrfCIGM7pJ4BP2h1/ZcP0RCoxegV+9asBu+/r cwr7T23+RZupoc/wnpvOFaqleLGz28E7JyQfcYUFQaQeoqmt0mzVZkRVtbIqjtpu1rsn DX5m4hVKPGEHxm9vA/SdQ7LLZuTd19bBeHhh621RDFnQCQGJT1DaEx/EcmiVSlHptint 3gvlzTf9gsyrPWs46hG3GuWqqr7k00MWwaKAjalzH+sq6kFr6h89n39iR1lLJJr8Stsl l+1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=SOZ+7B5P7TLqgXOsnD9r+OFaoY8xtrr371vnomrX2+0=; b=Y2ThquCQtKuK3kZSZndn1+mp+9MmaG+BstH0dgGi6IQJMCWECdJ4ds/pttHOdvB5HC ddD3oLdHPVZFDsx9s1+SZCn0kPhOkYhZ3QV49PcV0CW/xrnF0RWX2rtteJqnBcCnJAE2 YtscBuguC4z8l2ucDu4DJx+nV9ca40ovwZHyM1wH+dJMmCB+TXoeRSVBZOudKB/drjiC zlRJJtJEkRx/J9emgwvPSOSEAjM92JYvL8Vsnh0kt82ogWDCMqkZzmedkz2jVsn2ofta zkp0TPnPyopXHVKy7tJMNFJeglph71AcvFJe1rhwfuPlxVOiCqj4d+M7GHhe4ObwPBDB uDXg== X-Gm-Message-State: AJaThX7EqjC15+f2uHuemPUCC2boEIBWVWgascSywrcrH1TojU6Z9i8p I+d7OpVzxHL9VB9rFXge3UPkaQ== X-Google-Smtp-Source: ABhQp+TIa4SpDNxiALxTqHirQY7hVKH+mxd5jIpshJQvs+VuBtlsrVyCkwgiN7sKpcDNSdBPl3vpog== X-Received: by 10.98.31.215 with SMTP id l84mr1941785pfj.36.1510178389516; Wed, 08 Nov 2017 13:59:49 -0800 (PST) Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z8sm7979262pgs.41.2017.11.08.13.59.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 13:59:48 -0800 (PST) To: iasa20@ietf.org References: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> <6B399B19-037A-4F59-A35C-73FEF074F7C1@gmail.com> <20171108214708.3twjdffmjhknqarz@mx4.yitter.info> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 9 Nov 2017 10:59:52 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171108214708.3twjdffmjhknqarz@mx4.yitter.info> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 21:59:51 -0000 On 09/11/2017 10:47, Andrew Sullivan wrote: > On Wed, Nov 08, 2017 at 01:27:49PM -0800, Bob Hinden wrote: > >> I think our fund raising difficulties have little to do with how we are organized. > > Well, this is just an anecdote, but it matters in at least _some_ > cases. I personally made appeals to people whose response was, "Why > should I give more money to ISOC?" Our answer today has to be, "Trust > us, it's a dedicated fund," because we don't have a different > governance organization controlling the money. > > Now, this might have been because of the people I was talking to, and > their peculiar focus at the time on governance issues. But it > certainly isn't an objection to which we have an obvious retort. As in "Which word in 'dedicated' don't you understand?" ? I'm not denying that some potential patrons might suffer from this confusion for a few minutes. But since it's only a matter of some clear wording about separate accounts and dedicated funds, I truly find it hard to put much weight on this argument. If we don't have that clear wording already clearly displayed, that's a problem that should be soluble within a few days of deciding to solve it. Brian From nobody Wed Nov 8 14:07:35 2017 Return-Path: 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 F0FD2129400 for ; Wed, 8 Nov 2017 14:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 lXTUDN_TLCiA for ; Wed, 8 Nov 2017 14:07:32 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF541274D2 for ; Wed, 8 Nov 2017 14:07:32 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id o7so3005197pgc.4 for ; Wed, 08 Nov 2017 14:07:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4dqBHtygCJlkPmUPPCUeCCUB+879MdlKZPERsou2BYc=; b=cxUHzbmUuowIHJRvAoq9+LLWoBZRKQxdmzQtz/Q48JIjL/n+cpk242ocSNDhJl8y5q WspwdZOiaKGasTnExbgB5FOf+fCejjzENtVjks86Joo4JH20cQ4PgQy4qHxJ0sTWNEDd iBSo7n61mLQ4v/6pJO11l+vpg5VsNYhYbd+KkOWP+Zs4U5ZhviN4UW6VTFYiprkEnvkh ze5A7PxPAKlbBLd1phLrM/FjM89sREG/ToMXAcSUV9uEcQnVyVean1GxVNxMV6OzKym+ t7qOJMgTzigUBI931PD0rh6BvcA0e2DVgJx8iLP3/sTbCw1yilnHQy6zZih/ZN8HBZsd vscA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4dqBHtygCJlkPmUPPCUeCCUB+879MdlKZPERsou2BYc=; b=BCwjSkfdY+4JFCLzhkxbQWcwsPek5I+M/RrVDX5WkFTnYTjuDF9QhHFyiLpQZ0L8qa i6pgLeXxC2p/dpBspyJm8a91S/yPCRl0jva7NnbF1XKLj+eiI7mh+9TamxZo6N9b0Smd uOWK4K6agSY7YtRvqg/L3vXm0hLHkPjgII2HoCGgiEkH4QUCfn8co9LzG1xxVwzjRHXA GTHnaGd5xenEt38RcNBpfM9w+pS02mX0oidbSw9A9OWxA0xiH9MtLi0m+qV7hqEA4QNH ne0nHjf6RUIwuYhpkem4sE0Viw+dBpLrc3FcP0H0ZOeY4rfVQhSx+kVV5/EsnGEvl54G pj0A== X-Gm-Message-State: AJaThX7Zu7/qrTDyNZfEM2FER+veRHyVnX0jQV+eBM6dw7KqS0QCwAwt TZDXzsSs+wpMjDhdwEFHnvI= X-Google-Smtp-Source: ABhQp+RfzHjJOmwNK2jqJTlD+bZ1WCbLRopmfuP75+ftpFyTOIJ4TfBEhm/4P7aIbv8UMCEnME38lg== X-Received: by 10.99.143.29 with SMTP id n29mr1811143pgd.121.1510178851895; Wed, 08 Nov 2017 14:07:31 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id m74sm10409372pfi.2.2017.11.08.14.07.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 14:07:31 -0800 (PST) From: Bob Hinden Message-Id: <2EAB39A6-4532-4DFA-B713-DBD0D2355D81@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_BDF854C3-5959-49FF-8EA0-8DD3B51C82A4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 8 Nov 2017 14:07:27 -0800 In-Reply-To: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info> Cc: Bob Hinden , iasa20@ietf.org To: Andrew Sullivan References: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Some comments on draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:07:34 -0000 --Apple-Mail=_BDF854C3-5959-49FF-8EA0-8DD3B51C82A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Andrew, > I am particularly concerned about the staffing issue. The IAOC's > current job is oversight of the IAD and under IASA++ it might get more > such oversight responsibilities. But the difficulty is that the IAOC > is not ultimately able to make the normal decisions a supervisor can: > hiring and firing, promotion and pay. For many years the IETF was I don=E2=80=99t think that is correct. When I was the IAOC chair I = wrote the IADs performance reviews, goals for the next year, and = compensation changes. The IAOC approved these. It had to fit into ISOC = personal structure, but the decisions were made in the IAOC. I assume that is still the case. Bob --Apple-Mail=_BDF854C3-5959-49FF-8EA0-8DD3B51C82A4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloDgB8ACgkQrut0EXfn u6ittAf/cQRpaON9csNSGvfEz72xW1JDVWhNq9B93TcQ+E3wXBYUrQZ6QUhFu9y7 XKugmPQeQ/9QZFZ3fgSkh4WNICuD3YINj1kqZvd3EPzsv51JT5OYsAAUzEkzn7SL RvPAjT1q+whgWITm+f1ifBHpSmstJZg3sYhOQC6qSyYkEN/Mtbom8O3EPKdG4i0q s9dPLErvReorWWboJIb72m+j5SuLxOrSX8ydvIfjrfGevxUoCHjBflKZOGnrwqR8 /CPAUEoCQ4AKG0trPP9FJzd4tFTkNngNbArBMn54/aIjJ+4HggB2FcqJxiBSyf1z J1pTFV8ka07GLPCJjaSX8PYVGpmf/Q== =HWc5 -----END PGP SIGNATURE----- --Apple-Mail=_BDF854C3-5959-49FF-8EA0-8DD3B51C82A4-- From nobody Wed Nov 8 14:07:57 2017 Return-Path: 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 A458F129400 for ; Wed, 8 Nov 2017 14:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 eEClDR9jAY5A for ; Wed, 8 Nov 2017 14:07:54 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF0E21271FD for ; Wed, 8 Nov 2017 14:07:54 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id t10so1985025pgo.3 for ; Wed, 08 Nov 2017 14:07:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=oXtPxx6Kjh+pHWw/OW2aduUmj4L0IYrA51APor5KmKY=; b=q7kdySliCpfjDgruhTtTItNehPXZ3KNW19xh0yKswblkDdxqz7Rinjts8/vM4NRDcp +5ZVYzqLPzE33MLBv4zKNgjwZI2w2AHZLO/hNwXU0s+xRwReti7bfUF6q8+gHUDQzxVi iwqj/tsuwO0BnAN5ZYNWemHFEWtGpNiPBP7qWha901HkR8F15j4l8sis/y0q649vFGqk xl6AaYU+v6gEaIm9clhgV0ji64c1x9aki3BTxt3I6hNewDefEmZvX//f7zz5ZU/STD74 +p0YhiAccIHQvQ+IKrUq6jcWVHA/z8UONANE/F8GYcgseRcdAnxeDmujtrE+YMnBt81d aY7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=oXtPxx6Kjh+pHWw/OW2aduUmj4L0IYrA51APor5KmKY=; b=gB2UYxdqEAIODQN34rrhBbguMURk151ccv5UoXrBmq4D/3VyFy+7IsBkbGqSJn6WH7 WLw31GyafEaNC6yMA/QXgDLjlXUmB5MeS1d83bVDjLeaF0dSZ3ziPehU7/lxS/Tq5sX5 p4TkmmHYNkYygt9eVM2mp5CRLFc7WLBq3Sr+MzQPlQD2dAlISJ+bV+5ln7hLcLXXSh+U pc4TgW57+EY9KxktVyiDbpHASdKuJ63HnKhWGtnl8kEFfODF83AUwOvUGPrO5fdb0WC9 lL65yL3WyTZIzD6gOILBXptc2wTykfnbLJDFkEY+01uf2ICDQzDS+C0Q0IVAD4sUy9Dw 04eQ== X-Gm-Message-State: AJaThX4BqhGBCHo5yMPbMIX9i19GNCUe7NShp+Thfza7qYWazfH/SP2D ESt/Rric0xJWyVA2+tajMkQfrg== X-Google-Smtp-Source: ABhQp+Rt83MWCwJio39XDA2OKiucYvLj7xmDExjcv94TzVYIkNvc+ED2/fQiQh7x2MOI9/h17KOilQ== X-Received: by 10.101.100.68 with SMTP id s4mr548485pgv.451.1510178874009; Wed, 08 Nov 2017 14:07:54 -0800 (PST) Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b9sm8686386pff.48.2017.11.08.14.07.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 14:07:53 -0800 (PST) To: Andrew Sullivan , iasa20@ietf.org References: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info> From: Brian E Carpenter Organization: University of Auckland Message-ID: <28976c5c-9307-9079-9eb1-f7c791c16a89@gmail.com> Date: Thu, 9 Nov 2017 11:07:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Iasa20] Some comments on draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:07:56 -0000 Andrew, On 09/11/2017 10:40, Andrew Sullivan wrote: ... > 5.1.1 describes IASA++. There is a critical sentence in that > subsection that describes a central issue: "The IETF needs to be able > to make its own administrative decisions independent of ISOC." If we > take this to be true, then IASA++ is simply not an option. To me that's simply a non sequitur. IASA++ != IASA. It's IASA with the observed bugs fixed. Clear separation of the accounts and of decision making concerning those accounts is one of the fixes. That's an ISOC executive decision; I don't even see why it would need an ISOC Board motion. The same applies to correctly charging all ISOC staff time concerned to the IETF cost centre. That sort of cross-charging is standard procedure in every organization of any size. Doing it via a subsidiary is just a complicated way of achieving the same result. Brian From nobody Wed Nov 8 14:11:24 2017 Return-Path: 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 F2D261274D2 for ; Wed, 8 Nov 2017 14:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=HFFhLpuS; dkim=pass (1024-bit key) header.d=yitter.info header.b=gejldWqZ 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 u3YkcR_wkBzB for ; Wed, 8 Nov 2017 14:11:21 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7001271FD for ; Wed, 8 Nov 2017 14:11:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id CFB21BF56B for ; Wed, 8 Nov 2017 22:11:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510179080; bh=OyozG36JFoz/8Z8pD3u5JD/B9Wsf9iK3FQ/JFegdQII=; h=Date:From:To:Subject:References:In-Reply-To:From; b=HFFhLpuSEv337HfAVnP+Y6AkC69F/XSbNi4QU2zyMSWOPCtLln8BVRmALhlPKAMU4 m7jaenJ07WDEtBiFaeppfpIcPhBpX4F8d03k7vzbG9YJuTFNdeLFhjp899wN4MHDbm qAUBafdYczcIiFvPtbJdRWHDFXnT1lbXwqKj4uYY= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q695rm7ovy2z for ; Wed, 8 Nov 2017 22:11:19 +0000 (UTC) Date: Wed, 8 Nov 2017 17:11:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510179079; bh=OyozG36JFoz/8Z8pD3u5JD/B9Wsf9iK3FQ/JFegdQII=; h=Date:From:To:Subject:References:In-Reply-To:From; b=gejldWqZ1NJZYAu3rrNoUQrjXHKL5P9PSFROPc4t1iyp+beE9qa+ju+DbJOxNciOt 8ruAMbfQp2yn6CdkkcQm5hNCKOWk/owsIYxsSBtO7Z2Q2SPO2EAH9JdsfOwZ/sbpXY z0nWukIT/6nv+7KaF1o8j0miTsinOUmab9zYJqRE= From: Andrew Sullivan To: iasa20@ietf.org Message-ID: <20171108221117.ebpebuxj7zdforsw@mx4.yitter.info> References: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> <6B399B19-037A-4F59-A35C-73FEF074F7C1@gmail.com> <20171108214708.3twjdffmjhknqarz@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:11:23 -0000 On Thu, Nov 09, 2017 at 10:59:52AM +1300, Brian E Carpenter wrote: > As in "Which word in 'dedicated' don't you understand?" ? > > I'm not denying that some potential patrons might suffer from this confusion > for a few minutes. But since it's only a matter of some clear wording > about separate accounts and dedicated funds, I truly find it hard > to put much weight on this argument. If we don't have that clear wording > already clearly displayed, that's a problem that should be soluble > within a few days of deciding to solve it. I disagree. First, a "dedicated fund" under the control of the same entity is an accounting fiction and little more. (You can set up rules around the fund, but only if there's a trust can you prevent those rules from being changed.) People who work with money all day long know this perfectly well, and ask questions that reflect that kind of understanding. We don't have an answer for them because there isn't one. So, we're relying on transparency and reputational damage to enforce this. It's probably enough, but that brings us to our second point. >From the point of view of someone having to go to his or her board to approve a large dontation to the IETF, they have to explain why the IETF needs the money. Money is fungible. So the board people will naturally ask what ISOC is doing with the money the organization already gives ISOC, and then our fundraising needs are immediately bound up with everything else that ISOC is doing. If you want to ask money for your activity, you have to be able to show you have control of it and that it can't be used in the service of something else. To make that work, we have to divorce our pile of money from ISOC's, or else we are just one of the many things that ISOC is doing with its money. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 8 14:12:56 2017 Return-Path: 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 539701274D2 for ; Wed, 8 Nov 2017 14:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 yxXn_C4JdQyd for ; Wed, 8 Nov 2017 14:12:53 -0800 (PST) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF551271FD for ; Wed, 8 Nov 2017 14:12:53 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id a8so2752328pfc.0 for ; Wed, 08 Nov 2017 14:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=g6lo8Al3TY4sa48yCHNeWSwETYgjJEicykDl7LctsMs=; b=eeOHttcV+OVYrsT0GnZCyN57Kcc+l36riymaQdtevvOC9xRRVKaQ3izQz1N0NlzbK/ GFpUdDA7XMUFcSdFic8Y9fooILxnb03JxE8o0WLtB1tF8oqMkXW/a+TS3FflWAkIRSVj EGNCpTPZ6ojuQJjKrE1rd1VmeNZ4G04cFH0awDE4hlO6aDvo+XjXUq4l0QLLMod8NZOa UNSWTCb+lfV6v8wuZN/fTsRO7+OBzEQ/sf5HEN42+lXgYXuuEi7QPn1XmLa5Dwy67IuR 0+bPl5uvjphNft23i1MXTbY5MMlP8i1r1C1Z/2ZKtwYRorLDAY7WKDZ6svmuBSyHcxFL NaJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=g6lo8Al3TY4sa48yCHNeWSwETYgjJEicykDl7LctsMs=; b=KTONZudw/nkmYikCI9faLV/m9CPftGU5wH2MU8ZVZDyn1frRe3FUTzdSZm2b54Oa+E 7gUdXyasoxqsdfojurexlSKbJhnX2r1muBC4WMCa/9HagssexRo87sldnbt7cI3xE7A1 QBkT/rfc2OSF4uV8LKkbqEQxCy8es9OrbxPlIQYbdAHy3HSSBBCzYPvMwAIfxF1XRN8g xtuYys+Wnp7JyEoYN8VkPas4xEMQEUF1bPqO0Aew7dAGNBZMfbgG/hHkVavY7OUlRBcb P9etwZsGhSHokgvLA5CazuR6Rgh0MmaYXJiwuujyn/Ymr5j4Bzl4fJF3OsXLTLy9qtdf 6w9Q== X-Gm-Message-State: AJaThX5LYyF+aza24oPs/ZkloZnGl6k8Mhr5MREn1pp7ZCBq2Brv+K4h dvZz99Scd203WgG6SSxKCFblP+Tc X-Google-Smtp-Source: ABhQp+SivRzjW52sZhKJMWzMDEySZWNumk9iPpS/+eBi5ceQaQiPrePy+Fwk5u/Ged3XkybK8ovYjw== X-Received: by 10.84.128.227 with SMTP id a90mr1766247pla.224.1510179173211; Wed, 08 Nov 2017 14:12:53 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id a25sm8020366pgd.36.2017.11.08.14.12.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 14:12:52 -0800 (PST) From: Bob Hinden Message-Id: <20D7C285-1152-4275-831F-7DA7AAC19902@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_021AE351-F006-468D-8E27-A53590BEAB75"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 8 Nov 2017 14:12:51 -0800 In-Reply-To: <20171108214708.3twjdffmjhknqarz@mx4.yitter.info> Cc: Bob Hinden , iasa20@ietf.org To: Andrew Sullivan References: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> <6B399B19-037A-4F59-A35C-73FEF074F7C1@gmail.com> <20171108214708.3twjdffmjhknqarz@mx4.yitter.info> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:12:55 -0000 --Apple-Mail=_021AE351-F006-468D-8E27-A53590BEAB75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Andrew, > On Nov 8, 2017, at 1:47 PM, Andrew Sullivan = wrote: >=20 > On Wed, Nov 08, 2017 at 01:27:49PM -0800, Bob Hinden wrote: >=20 >> I think our fund raising difficulties have little to do with how we = are organized. >=20 > Well, this is just an anecdote, but it matters in at least _some_ > cases. I personally made appeals to people whose response was, "Why > should I give more money to ISOC?" Our answer today has to be, "Trust > us, it's a dedicated fund," because we don't have a different > governance organization controlling the money. >=20 > Now, this might have been because of the people I was talking to, and > their peculiar focus at the time on governance issues. But it > certainly isn't an objection to which we have an obvious retort. >=20 How is that going to be different if ISOC is still providing most of the = funding for the IETF? It=E2=80=99s not going to be hidden. Of course, some time people raise issue like this as a nicer way of = saying no. Bob --Apple-Mail=_021AE351-F006-468D-8E27-A53590BEAB75 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloDgWMACgkQrut0EXfn u6jBfAgAgoWNNiLRUon8jdWFlFv5gPBiVq4JeWINDDH7ih+oeSpD9u7VjGMKF3H5 dkiVwiqEj6jaRseqOUOHyj77QpFLYI7nF6WYx+Rwt/2H8KMCC7ZFgvH6OyId7N/m iZz4BKYPpS1tT98U2OEIuhVAygzv36q+BiYIddXwMfCEKqimIt6OqrKUodcSEAQ4 rdDp4Kx+6ElmGgp58t8maeswFxuUTk3gB3aDFV4R1j5SZ4ylNFJpp7IasxIGzMbl NeiJad127xWCOR/cLHx83oi6n711NhB9ey7GHF1//w0sy3b68i3xJYU2qaDrb3Eq iHCqkawoVyjyTz992KWpaSkjepGd2Q== =seR5 -----END PGP SIGNATURE----- --Apple-Mail=_021AE351-F006-468D-8E27-A53590BEAB75-- From nobody Wed Nov 8 14:13:22 2017 Return-Path: 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 AA2381271FD for ; Wed, 8 Nov 2017 14:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=QP2ymXMU; dkim=pass (1024-bit key) header.d=yitter.info header.b=dt9YHuZ8 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 okGHaci9NOjz for ; Wed, 8 Nov 2017 14:13:20 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BFFF129400 for ; Wed, 8 Nov 2017 14:13:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 8EFDABF56B for ; Wed, 8 Nov 2017 22:12:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510179169; bh=78Xlsyf/9T0/p6MxXJZQhb2kF45+oi7XWD8/m3mifhI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=QP2ymXMU9ijSdYmzYU5sQa1ZAOXHIUx41HhUZ3iWKPfLfVTWRcQB711Ob1updwwn1 eksy95GmehOllXb8n6RlsKL8dj04/JoDTsayxyi7/rfsOpNHlRz62J0dGzcGKrhDBM xGpapGS2uFbY+tUWoBMqESYtmmHeaNYINJvi7Al4= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKmiRHU9dmYK for ; Wed, 8 Nov 2017 22:12:48 +0000 (UTC) Date: Wed, 8 Nov 2017 17:12:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510179168; bh=78Xlsyf/9T0/p6MxXJZQhb2kF45+oi7XWD8/m3mifhI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=dt9YHuZ8gUbQ7RYlXSVtlflyVl7c5fKlEf2Gv4rsYtlgDn8UFF+TQGRCqCmgAI+HK 7d9djnUL86KZAerXak5jr3ldcZ/JM7VbSyhgxVGldKBRjO1Cwv2ChB2ACQvnjBOqxc F+91HpS6yPAMIVeOVPgHk18bEOD3zK5Uhy7ERokA= From: Andrew Sullivan To: iasa20@ietf.org Message-ID: <20171108221248.46uzlh5quzbflbwy@mx4.yitter.info> References: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info> <2EAB39A6-4532-4DFA-B713-DBD0D2355D81@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2EAB39A6-4532-4DFA-B713-DBD0D2355D81@gmail.com> Archived-At: Subject: Re: [Iasa20] Some comments on draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:13:21 -0000 On Wed, Nov 08, 2017 at 02:07:27PM -0800, Bob Hinden wrote: > > I don’t think that is correct. When I was the IAOC chair I wrote the IADs performance reviews, goals for the next year, and compensation changes. The IAOC approved these. It had to fit into ISOC personal structure, but the decisions were made in the IAOC. > > I assume that is still the case. When I was on the IAOC, we also write the performance reviews. But the plain fact is that the decision is not actually the IAOC's. It's ISOC's. ISOC is the employer, and that creates legal facts that we ought to be attentive to. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 8 14:16:05 2017 Return-Path: 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 99B5D1271FD for ; Wed, 8 Nov 2017 14:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=YeVu2NhL; dkim=pass (1024-bit key) header.d=yitter.info header.b=BOQbIj6H 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 2rsl381UZHDB for ; Wed, 8 Nov 2017 14:16:02 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A92126C2F for ; Wed, 8 Nov 2017 14:16:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 187CEBF56B for ; Wed, 8 Nov 2017 22:16:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510179362; bh=d1bpKGmxuHH2s8FrMBFC/9ufsXgBmDUaKtYs7o14/F4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=YeVu2NhLEkq1fexGEGSXO4sXMEVuQZ0Fge1HbR7zC2D40QjEnfxxbsCYKZ3SpAXoY PRJ6bUNFVJI4ClmmhH8a3TL6KM8GlCzXA8su+YB6wF1wKvUBQ9+Mgs0x2QfNtmZbeA qyvXU+u7sGVtjRAWEbEPgIfLKG6T7hgQISIRnlew= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSiyp-OSXtho for ; Wed, 8 Nov 2017 22:16:00 +0000 (UTC) Date: Wed, 8 Nov 2017 17:16:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510179360; bh=d1bpKGmxuHH2s8FrMBFC/9ufsXgBmDUaKtYs7o14/F4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=BOQbIj6HJJvWSO8HdVmSbGtApal30hEZ4ATV6tcTrvwCIGFzyJPoFK3XObcxel1/q 8hzzM2RS0Ybd+PHprNL9hyTkKn/+OeBUIx/m9tj1bPmMsOYC08A5+Uinz3D/eW2NRl OrfabYuJqsobvW0Xoe3Zzem4iay0OTuQ7XwNkcow= From: Andrew Sullivan To: iasa20@ietf.org Message-ID: <20171108221600.twlrk776mfjcciiw@mx4.yitter.info> References: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info> <28976c5c-9307-9079-9eb1-f7c791c16a89@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28976c5c-9307-9079-9eb1-f7c791c16a89@gmail.com> Archived-At: Subject: Re: [Iasa20] Some comments on draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:16:04 -0000 On Thu, Nov 09, 2017 at 11:07:55AM +1300, Brian E Carpenter wrote: > > the observed bugs fixed. Clear separation of the accounts and of > decision making concerning those accounts is one of the fixes. > That's an ISOC executive decision; I don't even see why it would What you are describing is a friendly agreement that the ISOC executive will do what we say, not an actual legal state of affairs in which we make those decisions. Or, to put it another way, under IASA++ if we are dissatisfied then we have to set everything up _de novo_ under duress. This is exactly the same set of arguments that went around during the IANA is-PTI-a-separate-legal-entity debate. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 8 14:18:12 2017 Return-Path: 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 A79811270FC for ; Wed, 8 Nov 2017 14:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 H-pkCsrH-A2t for ; Wed, 8 Nov 2017 14:18:09 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9B5E126C2F for ; Wed, 8 Nov 2017 14:18:08 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id z3so13887786wme.5 for ; Wed, 08 Nov 2017 14:18:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dCRM+7PzZAVC1FZKNPCTaWj6ploQnZYEuL0laZFRBSo=; b=1/v6HNrz7bxAT+7WK34CeWkRmEyDSk6Q2nKyoyCWNOoMqndEZbb124ewtbQDLBsmUT Vbv7qiThacmwqhnKq9a6pd3hPIZL7jyRgeEsDXH12KZKyjPpITUj75HzCGs/Hr19D6JB kvkN+G9m+vX2jWu1L9pDXXGsc8m7+onZZlqIUxskDKjlh65c8yMox5tdersCrhwQ7v4w Dl+gG/R+4+7jDlHbFhG4/ovEjJTUUP0BIMgq5eB76p3avXXjgt1U4xOKS+3fk1Z3sIaD WEpbazygpBrTC6+a5GR5MxCKIh2s8o28vi6Li5QOj8fw1Mp5ZDls53PdgfHJTiTsHuih tRNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dCRM+7PzZAVC1FZKNPCTaWj6ploQnZYEuL0laZFRBSo=; b=OaF5OznO5Su9JBkhLJrIrclHM0E8Cm797jx5j+Tsarqsm3qwdAPeXUX/TJorJkqSBl z9JNZt38sNBHsLHxkuDON4criv8T7CeGUI8tbiCHR8BiQhLwM7wxJqPk3bq31jwzXwmP KzSbGIDO9bsaxGfAZ5UqyA6NC9ugqQc6LNaanXlwFRAQXyQP++08SX/WtdcDKrHYqCEl O6tMSZhABZe/n4ufhp72A7KStkCzENm/M8iPUGV8EFhJJ0436MQ51yKeWwi6PntCCBp7 gBfk6jECAJeG5tSs52y/VgC6FXbx1OP0j0wGwismT3R8GuB+07eSQj0zznyA1huRv/dy xNwA== X-Gm-Message-State: AJaThX6yAQeWYkm6RmvUhK6I8ZqPas7UKQ5JiPrq7hl4Oj+LKx0oPVff B6xE3/zus4EQFaIgljBES9lBPaXI4dec5V//ZLF9FB78 X-Google-Smtp-Source: ABhQp+Qh59Klv4DWdDG0wf7WWsoNU2GK+XX8Y8BbYVcNOskM6tgrML60eOs8r5aCiCJo9krViKmoNm6Qu6FVWPlPciM= X-Received: by 10.28.156.67 with SMTP id f64mr1453952wme.42.1510179487260; Wed, 08 Nov 2017 14:18:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Wed, 8 Nov 2017 14:18:06 -0800 (PST) In-Reply-To: <20171108221600.twlrk776mfjcciiw@mx4.yitter.info> References: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info> <28976c5c-9307-9079-9eb1-f7c791c16a89@gmail.com> <20171108221600.twlrk776mfjcciiw@mx4.yitter.info> From: Richard Barnes Date: Wed, 8 Nov 2017 17:18:06 -0500 Message-ID: To: Andrew Sullivan Cc: iasa20@ietf.org Content-Type: multipart/alternative; boundary="001a114b3208e2b7bb055d800f94" Archived-At: Subject: Re: [Iasa20] Some comments on draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:18:11 -0000 --001a114b3208e2b7bb055d800f94 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 8, 2017 at 5:16 PM, Andrew Sullivan wrote: > On Thu, Nov 09, 2017 at 11:07:55AM +1300, Brian E Carpenter wrote: > > > > the observed bugs fixed. Clear separation of the accounts and of > > decision making concerning those accounts is one of the fixes. > > That's an ISOC executive decision; I don't even see why it would > > What you are describing is a friendly agreement that the ISOC > executive will do what we say, not an actual legal state of affairs in > which we make those decisions. Or, to put it another way, under > IASA++ if we are dissatisfied then we have to set everything up _de > novo_ under duress. > > This is exactly the same set of arguments that went around during the > IANA is-PTI-a-separate-legal-entity debate. > I'm sitting back and letting Andrew do the arguing right now, because he's saying exactly what I would say, and better. It seems tautological -- if the IETF is to have control over anything, then it needs to have control, not ISOC. --Richard > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 > --001a114b3208e2b7bb055d800f94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 8, 2017 at 5:16 PM, Andrew Sullivan <<= a href=3D"mailto:ajs@anvilwalrusden.com" target=3D"_blank">ajs@anvilwalrusd= en.com> wrote:
On Thu, Nov 09, 2017 at 11:07:55AM +1300, Brian E Carpenter wrote: >
> the observed bugs fixed. Clear separation of the accounts and of
> decision making concerning those accounts is one of the fixes.
> That's an ISOC executive decision; I don't even see why it wou= ld

What you are describing is a friendly agreement that the ISOC
executive will do what we say, not an actual legal state of affairs in
which we make those decisions.=C2=A0 Or, to put it another way, under
IASA++ if we are dissatisfied then we have to set everything up _de
novo_ under duress.

This is exactly the same set of arguments that went around during the
IANA is-PTI-a-separate-legal-entity debate.

=
I'm sitting back and letting Andrew do the arguing right now, beca= use he's saying exactly what I would say, and better.
It seems tautological -- if the IETF is to have control over an= ything, then it needs to have control, not ISOC.

--Richard

=C2=A0

Best regards,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

____________________________= ___________________
iasa20 mailing list
iasa20@ietf.org
https://www.ietf.org/mailman/listinfo/iasa20

--001a114b3208e2b7bb055d800f94-- From nobody Wed Nov 8 14:18:56 2017 Return-Path: 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 00BBD1271FD for ; Wed, 8 Nov 2017 14:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 AQSoCZJPW2QX for ; Wed, 8 Nov 2017 14:18:53 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F441126C2F for ; Wed, 8 Nov 2017 14:18:53 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id p9so3020517pgc.8 for ; Wed, 08 Nov 2017 14:18:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Yh9cMnOE0aP4GRRi7Q014N7b32goAM868666qnhs3fA=; b=od3rqwbKLLRfhUAvqTu2ZJ2BZ7su7DeIcjB1Vf/buxYyuVaqZydM+U8kW6f7YVv3qO ItMEOHo2C3fwhyjck2KyWrrEaiEGKSkTdLyyZA8kdUdFQuTvOfllfQO5FjB/Yigou1Ob pBr3j5rtyM2+YNdgNbGpE3ONxQVF4+PGzXTjbOPNA4YTqSMILVGHLtYhXAISHP7hUeyu qRoL0RivyRd/BOw2XbStLRH9JMINuU7xfmraY4Y1ZOmX4am059D8Dmn2JG1ZdaNxYdVg 9SBS31RW10fkpUBgYGQAZslldiWPDJ9ArAaK6kf5hKV0S7LnMzIbHh9TZm6oQe9kgvfo E5XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Yh9cMnOE0aP4GRRi7Q014N7b32goAM868666qnhs3fA=; b=Rh+pz57wzhFalt/xYWoI5mQ9jJzCxoO+A8wKc6fZRB4fWh1XlBflVkVbLGyjvWbjv0 +8LBmpAWnTSYsq3+/tivF7nOxkqzq6PqMiXym4CCMedMaD9TxksswyX2020FVUM0Ceyd 1c+nuppiQInjT7tj47CLjprN15ZO2FQsgHQOOM4uFcf4bQjpjW4BNsQPQFNcq6gu6L9q sIBSjf4YtynxoG4/Y49Zsj4RwKUAl6mH/2Ce/cOjx2ALMKYOKpdgEPhxQfIiDVC2UN61 8pyZ/vm9YsMqhBpyFlsHfO6tYw7fYJbSi7xOlJPH32vc4aH4J46NuWI+f/TcCUw4GQeq M42w== X-Gm-Message-State: AJaThX4koghCdl1hgh2J6pniShMMZPvI0r+NtRpmh9JOhIHWuF4LXZxk ovJssmENiTmNWUn0QL7Ihe42EWRr X-Google-Smtp-Source: ABhQp+Sa3rglUdhSKy04qmLefKHrK5TzNI4C6Lwqy5pk7yWO1XlfyVF8Jyzq+qdcFNKKfiCzC2DCqQ== X-Received: by 10.101.81.70 with SMTP id g6mr1790580pgq.97.1510179533078; Wed, 08 Nov 2017 14:18:53 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id n19sm10539143pfj.52.2017.11.08.14.18.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 14:18:52 -0800 (PST) From: Bob Hinden Message-Id: <7097F0F4-59B0-44F6-B1B6-7CB60C0CBFCA@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_70EE1176-C6DB-4CE2-BC93-DAE6BC1FAAA1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 8 Nov 2017 14:18:50 -0800 In-Reply-To: <20171108221248.46uzlh5quzbflbwy@mx4.yitter.info> Cc: Bob Hinden , iasa20@ietf.org To: Andrew Sullivan References: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info> <2EAB39A6-4532-4DFA-B713-DBD0D2355D81@gmail.com> <20171108221248.46uzlh5quzbflbwy@mx4.yitter.info> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Some comments on draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:18:55 -0000 --Apple-Mail=_70EE1176-C6DB-4CE2-BC93-DAE6BC1FAAA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Andrew, > On Nov 8, 2017, at 2:12 PM, Andrew Sullivan = wrote: >=20 > On Wed, Nov 08, 2017 at 02:07:27PM -0800, Bob Hinden wrote: >>=20 >> I don=E2=80=99t think that is correct. When I was the IAOC chair I = wrote the IADs performance reviews, goals for the next year, and = compensation changes. The IAOC approved these. It had to fit into ISOC = personal structure, but the decisions were made in the IAOC. >>=20 >> I assume that is still the case. >=20 > When I was on the IAOC, we also write the performance reviews. But > the plain fact is that the decision is not actually the IAOC's. It's > ISOC's. ISOC is the employer, and that creates legal facts that we > ought to be attentive to. True, but in practice the IETF had control over the IADs performance = evaluation. To me that seems like the important thing. Bob >=20 > Best regards, >=20 > A >=20 > -- > Andrew Sullivan > ajs@anvilwalrusden.com >=20 > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 --Apple-Mail=_70EE1176-C6DB-4CE2-BC93-DAE6BC1FAAA1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloDgsoACgkQrut0EXfn u6iFXgf+Ky10XF2zQ9hk3ulsZ1KBuh4PhtDuueoJO3wZZ8ap71j48BuCl9MgqV3B oTMjpN3Wl7xWA/oED/ntfI3HEfhZooM/iCCRD7M9JKgT3U1S6+VEu6DaSHhj+B+G evOIvNTxEvlJd/D3cNJPgxxudchOMl3+/ek/7JFGpMg+/tVKAcOmcnIMbwg8zrFh pTu/pg6ZRSOt3ERmqDsrnsMsemAq4x7z06B+kIR/fUKVJziWnAGjwnRkqeCBon/t YP1/SuzaUOeKdMu/r4ARSvKRx6h3QoU8oxLPGNrrqsEUiRDGLR+yIcnIWkYkJlJP IlJU7H3QoFVcuX7lOJ/Ml9XkCKJTLg== =WfN0 -----END PGP SIGNATURE----- --Apple-Mail=_70EE1176-C6DB-4CE2-BC93-DAE6BC1FAAA1-- From nobody Wed Nov 8 14:23:34 2017 Return-Path: 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 7D696127333 for ; Wed, 8 Nov 2017 14:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 CfAVOSG68vg2 for ; Wed, 8 Nov 2017 14:23:29 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED1E12940E for ; Wed, 8 Nov 2017 14:23:28 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id q66so3821608wrb.13 for ; Wed, 08 Nov 2017 14:23:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4yRXBPCGrGtMHO61z4IivHRXshmCRgdCdbM7/3PTArI=; b=VhZ59ZiiVceSo8JIpgWZsfl4/W9bFh6y2iEgi5aaMSZSRQcPlv4io72CkkScz82xEt SWp9TfcSBU2/TPvJyYbanwT26PgazwYl7l2iaEP97mSDqkg/QLid9m1ngfc/nz9chym4 qVho1IjFGrG8Vr6gjmlU49U3n3KxZYhULlOM9F5ULy87fM408B1JztB38v7wDPaoUxuJ 21bLMXJ96nEzms5pRsN8oMnK8OZoN92fUd/5YfrKIeTPIP9do6Ke+6xe+1dJV3EBKwAj t86WnfItmmlyZheZj70ScSS5oq6FL9+CYhTaXBya+vQfNSly4XlLAUuKuQzW6ybfazR4 3mKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4yRXBPCGrGtMHO61z4IivHRXshmCRgdCdbM7/3PTArI=; b=l3Q7fvVoA9aWeW8GkP9FDO6O8DgYOucSVfpwpXCaVUgcHIHWb7zpFfL2NyaYy+kN9q 3neHs+EoXLmOI2SZOs27NMKWdMclpQNc5JgaIzsgT+qxEKxRo3cUCkh6Cgy4q3Lpq9Yo 2na7AqZGEemk3oUDJ4896YHyzlnAAU0kcoq0ivko5f3+yVxnRcOxvPgW+votyrTknVcg SOJSsd0TitDCEZvZOUMyXRYqghz4935JuCEFzIXLNUSfYHJs2FrpAxyUepqq3weU4f+G d65BpiIWVTUNAktm/3xJ1cFxKce6OBQBI1eWd2wdfPawCt4/P8GnvRBmutxprX/VTMdG fD4w== X-Gm-Message-State: AJaThX55x15diyWY+KSt3FwFBbe6J4j6LMLW49KM3/Ahrks71ZIn0z9m igncsVEPmuSa3ZSpmD5w2RHNtwtKiQgd0eQHZIM7xQ== X-Google-Smtp-Source: ABhQp+RbGW0K1WvIRSvCjmRE4MiF3ztr+xeW4FnimUP+bGRRs+7UsrYFewmaUXMNy+T0KnRDmIeqrYYAnpuPFef9/v4= X-Received: by 10.223.152.16 with SMTP id v16mr1571932wrb.108.1510179807141; Wed, 08 Nov 2017 14:23:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Wed, 8 Nov 2017 14:23:26 -0800 (PST) Received: by 10.28.174.81 with HTTP; Wed, 8 Nov 2017 14:23:26 -0800 (PST) In-Reply-To: <7097F0F4-59B0-44F6-B1B6-7CB60C0CBFCA@gmail.com> References: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info> <2EAB39A6-4532-4DFA-B713-DBD0D2355D81@gmail.com> <20171108221248.46uzlh5quzbflbwy@mx4.yitter.info> <7097F0F4-59B0-44F6-B1B6-7CB60C0CBFCA@gmail.com> From: Richard Barnes Date: Wed, 8 Nov 2017 17:23:26 -0500 Message-ID: To: Bob Hinden Cc: Andrew Sullivan , iasa20@ietf.org Content-Type: multipart/alternative; boundary="f403045d55a6f3bd57055d802256" Archived-At: Subject: Re: [Iasa20] Some comments on draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:23:32 -0000 --f403045d55a6f3bd57055d802256 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Nov 8, 2017 17:18, "Bob Hinden" wrote: Andrew, > On Nov 8, 2017, at 2:12 PM, Andrew Sullivan wrote: > > On Wed, Nov 08, 2017 at 02:07:27PM -0800, Bob Hinden wrote: >> >> I don=E2=80=99t think that is correct. When I was the IAOC chair I wrot= e the IADs performance reviews, goals for the next year, and compensation changes. The IAOC approved these. It had to fit into ISOC personal structure, but the decisions were made in the IAOC. >> >> I assume that is still the case. > > When I was on the IAOC, we also write the performance reviews. But > the plain fact is that the decision is not actually the IAOC's. It's > ISOC's. ISOC is the employer, and that creates legal facts that we > ought to be attentive to. True, but in practice the IETF had control over the IADs performance evaluation. To me that seems like the important thing. "In practice" is not really what matters here. Legal roles matter. If for some reason the IAD were to become totally unacceptable to the IETF, it would still be ISOC's sole discretion whether to retain, reassign, or fire that person. With today or IASA++, IETF can only cajole. That does not seem like it meets the autonomy and accountability goals we have here. --Richard Bob > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 _______________________________________________ iasa20 mailing list iasa20@ietf.org https://www.ietf.org/mailman/listinfo/iasa20 --f403045d55a6f3bd57055d802256 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Nov 8, 2017 17:18, "Bob Hinden" <bob.hinden@gmail.com> wrote:
Andrew,

> On Nov 8, 2017, at 2:12 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
>
> On Wed, Nov 08, 2017 at 02:07:27PM -0800, Bob Hinden wrote:
>>
>> I don=E2=80=99t think that is correct.=C2=A0 When I was the IAOC c= hair I wrote the IADs performance reviews, goals for the next year, and com= pensation changes.=C2=A0 The IAOC approved these.=C2=A0 It had to fit into = ISOC personal structure, but the decisions were made in the IAOC.
>>
>> I assume that is still the case.
>
> When I was on the IAOC, we also write the performance reviews.=C2=A0 B= ut
> the plain fact is that the decision is not actually the IAOC's.=C2= =A0 It's
> ISOC's.=C2=A0 ISOC is the employer, and that creates legal facts t= hat we
> ought to be attentive to.

True, but in practice the IETF had control over the IADs performance = evaluation.=C2=A0 To me that seems like the important thing.

"In = practice" is not really what matters here.=C2=A0 Legal roles matter.= =C2=A0 If for some reason the IAD were to become totally unacceptable to th= e IETF, it would still be ISOC's sole discretion whether to retain, rea= ssign, or fire that person.=C2=A0 With today or IASA++, IETF can only cajol= e.=C2=A0

That does not s= eem like it meets the autonomy and accountability goals we have here.=C2=A0=

--Richard


--f403045d55a6f3bd57055d802256-- From nobody Wed Nov 8 14:26:46 2017 Return-Path: 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 7DC97129400 for ; Wed, 8 Nov 2017 14:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jNSVq6cgj9_A for ; Wed, 8 Nov 2017 14:26:43 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35A5F126D46 for ; Wed, 8 Nov 2017 14:26:43 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id m18so3021089pgd.13 for ; Wed, 08 Nov 2017 14:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=KyDrXyd38VUP9AkasbAEs/BsOzQqzHLR5XEICtTuHq0=; b=DPhYgpyrtttCXseI17pyQDL04t+V36IiGBg5BUj88TFrFKOTB0M+qrAuF0vnxInMYB aZ5WH4b2xSGReN8QzNq0db14bBSdEjKkUvReXnxds8q/baRJdezX0HqBu3T26sj7yf3H AlHKoit40GOZD3LzerlvfAUh1yQ3mCCgQ1WJmRWR8VolU7f3w6e3gffEsti5cXp7LF6c T6vetFLt2eONI8i3E1fVEpKNosSkhGtkoBUJYBczWHKiziTUHdjlzwgKDL5HDsdMfQ7F vA5OIDwDDe43BMir+zsVStFihseXFtlUPA0H7gk7JUcwkjP4oHBevMuNMe+Qr6MWujlE KpgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=KyDrXyd38VUP9AkasbAEs/BsOzQqzHLR5XEICtTuHq0=; b=aiHxBwvCc5x/wlNbBk2JETlUhrAz+wzHb392wg+PENENWDynj7JCqAX6mDX3S8IiXx Wfrg58iePZLSESQwlmSjk9nl6+4wGzaD15wYWIg1QHv3ul1D97dmmRpyEiWPnFViA1M7 5GnyVdEgTVTdUW7Pu3GbOg2NW5VNphbHWFGAFWBA9RlZEWFwo8H0gGphxsmdAM5pLWkG KRN2Q45yD9Avh6cTd2Eq/xy5FEFNIaWiPMKIBSmJoESGkiXeiN9rJTxXP9XiXeJXzxUD 0oLmQFYH2DMjAV/xQrWmMpYq5W5IDDWWHT8shGVUMNT4V0X1bSvpSVRDLw8fpKcin+YX jEYg== X-Gm-Message-State: AJaThX6O6UaU4rsAQd64A45P+04nbLDoLQEXIEmr9eCPrVAaO+rFn2N5 atooH30UPWDxdt4HoSwBi2BBdg== X-Google-Smtp-Source: ABhQp+SaJtiqBO7/1wlL0ccUDfVvOj+wPtWao+bRdubsCySX8kxqcgMmDamr7C0L8N74LsBD6GYU9Q== X-Received: by 10.99.123.24 with SMTP id w24mr1816180pgc.438.1510180002574; Wed, 08 Nov 2017 14:26:42 -0800 (PST) Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e71sm9813799pfk.55.2017.11.08.14.26.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 14:26:41 -0800 (PST) To: iasa20@ietf.org References: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info> <28976c5c-9307-9079-9eb1-f7c791c16a89@gmail.com> <20171108221600.twlrk776mfjcciiw@mx4.yitter.info> From: Brian E Carpenter Organization: University of Auckland Message-ID: <586088eb-2ebe-f590-d351-7bbf415d42bd@gmail.com> Date: Thu, 9 Nov 2017 11:26:46 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171108221600.twlrk776mfjcciiw@mx4.yitter.info> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Iasa20] Some comments on draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:26:44 -0000 On 09/11/2017 11:16, Andrew Sullivan wrote: > On Thu, Nov 09, 2017 at 11:07:55AM +1300, Brian E Carpenter wrote: >> >> the observed bugs fixed. Clear separation of the accounts and of >> decision making concerning those accounts is one of the fixes. >> That's an ISOC executive decision; I don't even see why it would > > What you are describing is a friendly agreement that the ISOC > executive will do what we say, not an actual legal state of affairs in > which we make those decisions. Or, to put it another way, under > IASA++ if we are dissatisfied then we have to set everything up _de > novo_ under duress. > > This is exactly the same set of arguments that went around during the > IANA is-PTI-a-separate-legal-entity debate. Correct. And guess what I thought and wrote about that ;-). We disagree. Let's hear from everybody else instead of repeating ourselves. Brian From nobody Wed Nov 8 14:33:54 2017 Return-Path: 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 5C115127ABE for ; Wed, 8 Nov 2017 14:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Hox97HBLoh7y for ; Wed, 8 Nov 2017 14:33:51 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1013126D46 for ; Wed, 8 Nov 2017 14:33:51 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id p9so3050224pgc.8 for ; Wed, 08 Nov 2017 14:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pFom8QSvLND16tmKArZcb9pA+SqWg4z/6OGurq0neZs=; b=lIW/kA6PM2AhjgYupfXQ3dzrQIhuWbFkqYaIUK6DYQFDgh07GAZT49isxFwg122BNo L9HcMr0jSTWStFKgKY4oOJ7Cl6YQGMkL1GMwC6SCnR8HfL6293CMuEuVkBAZTL/CDfMH NGQRHyBwIylZ0f+97x6qHIjbf4yAI8lpWzFGqMZu/K339Yo72mEMf03EEN7g/p+Og/1t epRHyTCdPQLxKIxqOOGwOMd1D+nhTPXjfmULA2OelQ2LYQlzbQQnW1huvzHB/4vP6mKn 5X1qL6Y99tuvXUK7qM2cUJqjRwbCbjkdiCFVex2f1vTP9e4KZuTMi/fwY9wYLWfafoHQ GsMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pFom8QSvLND16tmKArZcb9pA+SqWg4z/6OGurq0neZs=; b=DvKVZnCVg9n7XgPmQNdV928LQ2T2+mE/4B29EUusXmEcW+lmvfOJVzEiRqq9+UFppe HtMQJGrpHrveCcgs5d+mqmx6IkJx1ajXkilOgvyWANNEL6ykzUWenmMk1GGR+sVmpxYa lPxxgpl5YsSUsvg3X7CNyKuJ+BIKhwemFqZeRjDkrgX6T+xw1xRD2zdEBOXWh9EJXb4d akZN8Ft+9bUl68V4+Wm4A5F5Wk8RnoSvR3H7OdFUOvJYZ5jGfgpGrrFREcUJhoCe5H/A Q/qCKXHTpJSLQykPfLtiLRNyRtk6toTu4v0RrgBjsovJFs6+HChXq4/mVtmZPqExVKFW kp1Q== X-Gm-Message-State: AJaThX4rw/FoAGMclw/Di8X0zQ5o1b/qnlt82FlATolxh1F2JSqaiyLf r6oE1pm8fS0kZC8CSU+AM2c= X-Google-Smtp-Source: ABhQp+TKoBbTQnfC0MMNeF8LJokCS10TegdDZLu9Caw1L21pXL2vT5uruPzQuwTPori6ZAb8mEyKzQ== X-Received: by 10.159.195.7 with SMTP id bd7mr1803215plb.43.1510180431188; Wed, 08 Nov 2017 14:33:51 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id t2sm10684804pfk.90.2017.11.08.14.33.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 14:33:50 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_96F29402-88D0-40F6-83C9-A7E0C94370E8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 8 Nov 2017 14:33:48 -0800 In-Reply-To: Cc: Bob Hinden , Andrew Sullivan , iasa20@ietf.org To: Richard Barnes References: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info> <2EAB39A6-4532-4DFA-B713-DBD0D2355D81@gmail.com> <20171108221248.46uzlh5quzbflbwy@mx4.yitter.info> <7097F0F4-59B0-44F6-B1B6-7CB60C0CBFCA@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Some comments on draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:33:53 -0000 --Apple-Mail=_96F29402-88D0-40F6-83C9-A7E0C94370E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Richard, > On Nov 8, 2017, at 2:23 PM, Richard Barnes wrote: >=20 >=20 >=20 > On Nov 8, 2017 17:18, "Bob Hinden" wrote: > Andrew, >=20 > > On Nov 8, 2017, at 2:12 PM, Andrew Sullivan = wrote: > > > > On Wed, Nov 08, 2017 at 02:07:27PM -0800, Bob Hinden wrote: > >> > >> I don=E2=80=99t think that is correct. When I was the IAOC chair I = wrote the IADs performance reviews, goals for the next year, and = compensation changes. The IAOC approved these. It had to fit into ISOC = personal structure, but the decisions were made in the IAOC. > >> > >> I assume that is still the case. > > > > When I was on the IAOC, we also write the performance reviews. But > > the plain fact is that the decision is not actually the IAOC's. = It's > > ISOC's. ISOC is the employer, and that creates legal facts that we > > ought to be attentive to. >=20 > True, but in practice the IETF had control over the IADs performance = evaluation. To me that seems like the important thing. >=20 > "In practice" is not really what matters here. Legal roles matter. = If for some reason the IAD were to become totally unacceptable to the = IETF, it would still be ISOC's sole discretion whether to retain, = reassign, or fire that person. With today or IASA++, IETF can only = cajole. I disagree, the IAOC could fire an IAD if they thought he/she was not = doing their job. ISOC would not stop this. >=20 > That does not seem like it meets the autonomy and accountability goals = we have here. To clarify, you mean the goals the design team has defined in the draft. Bob --Apple-Mail=_96F29402-88D0-40F6-83C9-A7E0C94370E8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloDhkwACgkQrut0EXfn u6g2OggAoZJhhqMYbTK2/navDO9q8vIOCA6jBG8bCG9UvGC5lZp6Zxolxj9LQI/e ssznndSwjzhUoRh/tBPCAUfVCY9hDJLs0CWV7ikhwBE8xG0at9HPzlD/DQjFkunE NPTYlJ9fZRMJaMs9qkHw5Kp6m030zhKTp7AyvTMjDCrpxRWeLQ+Qpfl9gvWISRSd z3dVNaCa5CGv7xZqzpmADCdBjNlhAOBfjlDHNVaDTpliagI/OT0asqnATPF1BahF dAo+xRg41Ltil5ZDhQlj8q5xNj25oB+8Ddasos8WxNTcug8jXjUDJUcH8MGIoCGV y4lmzoU2Y7c7rXp0M9NcXwBqzg+2xg== =JFbT -----END PGP SIGNATURE----- --Apple-Mail=_96F29402-88D0-40F6-83C9-A7E0C94370E8-- From nobody Wed Nov 8 14:48:19 2017 Return-Path: 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 84B2F126C2F for ; Wed, 8 Nov 2017 14:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xKGSOunB6TwC for ; Wed, 8 Nov 2017 14:48:15 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCDEB126C19 for ; Wed, 8 Nov 2017 14:48:15 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id p7so5444963qkd.7 for ; Wed, 08 Nov 2017 14:48:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FBxjpTbrWAE8AofVE9rN1jlVQkRZcSqNdcvnPjJS9ck=; b=G1+fsvHQQl673JPmVhEFttznBRx0W5J7GLQ9CXmIF0Ou8RQnIjmK5Q+DDyrmywT1en Bs7YE1U+W7Gn+t0zsZ+TtuEIxPCfDwTHeb8cFHVP1lVWVhnR5QkdZ2INX9S44/ySYOd9 dr+U/a7OW17Qmth6YQL1zpuigLA59yTSn86ew2LIBSLLmur+p8eTpTZXtNH3Ra4lmCyq C7UoT4MZ55QtuJb7D8sVgIlBmw3TnATTiBXw58+sksCoHzxKzy7r1/AdDhKRVx3jP083 hMQcYU5THYlf+Zxz7L396Yb9IuCn5mncnqJ/I0OgZ4NGqaf4586oxDPs75sAmPcymTcS pOag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FBxjpTbrWAE8AofVE9rN1jlVQkRZcSqNdcvnPjJS9ck=; b=mnvT3bQYwEBe9tK3AJPs2I76GUqQXLsoqioUe0PMzQNUuv1HO3Lp11iG90+jwru5Gs QPFHuPMOn9Hovo/06LoCNe5basXt9GlIx5hLx5OD9I4WvZNnwroj/9o2AP+TsNvQ1DbH PsxTWaeEzmkppoiy+DJH7WM2hzT0Itdw6CznSWARYxzTZ+MqRlcJuFQ/iH6yFg7ky7Cd 0UtWyU/heoDZQbAJcdTAOgCaI6ojl01Og1bvLFk+HSH3A8IX+70qelNEsCO+xp2TDFgk TqWzfZtd22OWGX9k3MoDxvPdlxLwGCR/O2+bUIn96Mx0LgRGZ+f9L6ZzmEEMXFS2ljmz vNUQ== X-Gm-Message-State: AJaThX6hbrGPMCPfztbharSJ02oymrp/64rd5DJZH9dBbN3Fk5F4OLRA VBJri7iinJR7rzLSi6JozBtJSu/HRaVQE3AB1fM= X-Google-Smtp-Source: ABhQp+S3owrlBv8Kve8fDmREg8VJ0Cy9thbU6vKEG06bt3uedD+HO8wdScRI51bChyKjfBneDfsmLyfMmoPFjrRiKEY= X-Received: by 10.55.186.196 with SMTP id k187mr3184455qkf.94.1510181294575; Wed, 08 Nov 2017 14:48:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.60.74 with HTTP; Wed, 8 Nov 2017 14:47:43 -0800 (PST) In-Reply-To: References: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info> <28976c5c-9307-9079-9eb1-f7c791c16a89@gmail.com> <20171108221600.twlrk776mfjcciiw@mx4.yitter.info> From: Ted Hardie Date: Wed, 8 Nov 2017 14:47:43 -0800 Message-ID: To: Richard Barnes Cc: Andrew Sullivan , iasa20@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0494109c1564055d807b96" Archived-At: Subject: Re: [Iasa20] Some comments on draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:48:17 -0000 --94eb2c0494109c1564055d807b96 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 8, 2017 at 2:18 PM, Richard Barnes wrote: > > It seems tautological -- if the IETF is to have control over anything, > then it needs to have control, not ISOC. > > --Richard > > > So, permit me to gently point out that this formulation is a touch wrong in our current circumstances. The IETF is an activity of ISOC. If the IETF has control over anything, ISOC has control over it. We are part of ISOC. A mental model I find useful here is that of the "business unit". In one corporate structure, you may have a bunch of different lines of business, each constructed as its own business unit, but all part of a single corporation and reporting up to a single board. In a different structure, you may have each of those lines of business constructed as subsidiaries, each with its own P & L, corporate structures, and related to the parent primarily by the ownership stake the parent has. In a different structure yet, each of those is independent businesses without a single corporate parent but with a substantial commonality of individual stockholders. In our current situation, I think folks believe that we need the "IETF line of business" to operate in a way that is different from other work done by ISOC. We need to be transparent in specific ways, and we need to take into account the specific needs of developing our standards. This document lays out three ways to accomplish it: IASA++: Reorganize ISOC so that the IETF line of business can operate differently within ISOC, in line with the needs identified. Subsidiary: Reorganize ISOC so that the IETF line of business is in a distinct subsidiary that can operate differently, much as PIR operates differently from ISOC's core operations. Independent: Spin the IETF line of business out, such that it operates without reference to the way ISOC operates. We would remain closely tied in purpose and membership, but absolutely distinct from a legal perspective. This mental model may not work for everyone, of course, but it helps me remember the options simply and relate them to other experiences. Ted --94eb2c0494109c1564055d807b96 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 8, 2017 at 2:18 PM, Richard Barnes <rlb@ipv.sx= > wrote:

It seems tautological -- if the IETF is to hav= e control over anything, then it needs to have control, not ISOC.

--Richard<= br>



So, permit= me to gently point out that this formulation is a touch wrong in our curre= nt circumstances.=C2=A0 The IETF is an activity of ISOC.=C2=A0 If the IETF = has control over anything, ISOC has control over it.=C2=A0 We are part of I= SOC.

A mental model I find useful h= ere is that of the "business unit".=C2=A0 In one corporate struct= ure, you may have a bunch of different lines of business, each constructed = as its own business unit, but all part of a single corporation and reportin= g up to a single board.=C2=A0 In a different=C2=A0 structure, you may have = each of those lines of business constructed as subsidiaries, each with its = own P & L, corporate structures, and related to the parent primarily by= the ownership stake the parent has.=C2=A0 In a different structure yet, ea= ch of those is independent businesses without a single corporate parent but= with a substantial commonality of individual stockholders.

In our current situation, I think folks believe th= at we need=C2=A0 the "IETF line of business" to operate in a way = that is different from other work done by ISOC.=C2=A0 We need to be transpa= rent in specific ways, and we need to take into account the specific needs = of developing our standards.=C2=A0=C2=A0 This document lays out three ways = to accomplish it:

IASA++: Reorganiz= e ISOC so that the IETF line of business can operate differently within ISO= C, in line with the needs identified.

Subsidiary: Reorganize ISOC so that the IETF line of business is in a di= stinct subsidiary that can operate differently, much as PIR operates differ= ently from ISOC's core operations.

Independent:=C2=A0 Spin the IETF line of business out, such that it ope= rates without reference to the way ISOC operates.=C2=A0 We would remain clo= sely tied in purpose and membership, but absolutely distinct from a legal p= erspective.

This mental model may n= ot work for everyone, of course, but it helps me remember the options simpl= y and relate them to other experiences.

Ted
--94eb2c0494109c1564055d807b96-- From nobody Wed Nov 8 14:50:01 2017 Return-Path: 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 9A4A012702E for ; Wed, 8 Nov 2017 14:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=LrduNwlk; dkim=pass (1024-bit key) header.d=yitter.info header.b=FPoEBiwa 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 Ka6F-k1Rel4Z for ; Wed, 8 Nov 2017 14:49:58 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7A1126C19 for ; Wed, 8 Nov 2017 14:49:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id A4877BF56B for ; Wed, 8 Nov 2017 22:49:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510181367; bh=pydITbiLV6WgsKFtKyYS3zBlFnXK5lNi8S5u3vbbgnM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=LrduNwlk+cBkvaNMrgl3rvoM+H6aBu8JnpnMIgHXof/yYwvwYMvsoGCczHC5exJUC b4hTULQkeZYqWJ6Oo7egq+N6DgX5o/HOnqi3SBmxVgvC8isww7TtzptVcAsR/nCSgY xeDqIIfCxRz0KmvILj1RYX1Lpg5rXMRKgCB3z0To= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-h8XaCGKY4S for ; Wed, 8 Nov 2017 22:49:26 +0000 (UTC) Date: Wed, 8 Nov 2017 17:49:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510181366; bh=pydITbiLV6WgsKFtKyYS3zBlFnXK5lNi8S5u3vbbgnM=; h=Date:From:To:Subject:References:In-Reply-To:From; b=FPoEBiwaV1iB4ZrI6wDTZ5gzRGGbi5uAYCJrOJoFiE6AjSQWwgCP9/9ZhEBJAz8hj GC012OTtWohUY9B/HnxmMOjk953EIZqXiS4HLCK2113QkLRwajmR7mWnwNQWvWBkvx r5NgA5V2ru4PE3m+OyG3Rf893dBKrEcm0QJaNwFE= From: Andrew Sullivan To: iasa20@ietf.org Message-ID: <20171108224924.beyzd6zmc3wsqj3j@mx4.yitter.info> References: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> <6B399B19-037A-4F59-A35C-73FEF074F7C1@gmail.com> <20171108214708.3twjdffmjhknqarz@mx4.yitter.info> <20D7C285-1152-4275-831F-7DA7AAC19902@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20D7C285-1152-4275-831F-7DA7AAC19902@gmail.com> Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:49:59 -0000 On Wed, Nov 08, 2017 at 02:12:51PM -0800, Bob Hinden wrote: > > How is that going to be different if ISOC is still providing most of the funding for the IETF? It’s not going to be hidden. > If you give money today to an ISOC fund that has a red "IETF" in magic marker on the outside, from the point of view of money people you have given the money _to_ ISOC, but with the intention that they spend it on the IETF. If they don't, then you might have had a reasonable expectation not met and you might have a legal claim, but ISOC didn't steal the money. If you given money to some future legally-incorporated entity called "IETF" and that entity has a bank account, then if ISOC winds up the IETF entity there are rules about what it can do with the IETF money, because it is not just the same as any other money ISOC has. >From the POV of outsiders, the second of these is trivial to explain and the first is a pitch that has lost them by the time you got to sentence two. > Of course, some time people raise issue like this as a nicer way of saying no. There are lots of reasons people might do that. But I want to make their job of selling us to their boards easier, not harder, and IASA++ does not make it easier. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 8 14:54:09 2017 Return-Path: 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 EA470126D46 for ; Wed, 8 Nov 2017 14:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=NYmcM4zX; dkim=pass (1024-bit key) header.d=yitter.info header.b=B4LmfHz9 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 Vsub5EQI3jdK for ; Wed, 8 Nov 2017 14:54:06 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E54126C19 for ; Wed, 8 Nov 2017 14:54:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 2AF70BF56B for ; Wed, 8 Nov 2017 22:54:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510181646; bh=S+EZu5SUXPB2UHbd9eP81ftC/wxSoaSxUKK3LXvM6W4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=NYmcM4zXuLMsvWX8PXPMcqT6c7Xoytme/XV2X8RdBCK/scOnLEZfHzWQGsigYcaVK XkHtAd+YrIOqTikqe38K6vjGdl9wWVvMa+ByRhVOwa7SJPKWFniCKbSnLDaE8EX3+b 6/hBo5Q2UT1KbAvuHNRqWafzKBxw2UfXu8MzvHxQ= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QerkKk4QKXWz for ; Wed, 8 Nov 2017 22:54:04 +0000 (UTC) Date: Wed, 8 Nov 2017 17:54:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510181644; bh=S+EZu5SUXPB2UHbd9eP81ftC/wxSoaSxUKK3LXvM6W4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=B4LmfHz91uIBaGv4CWfXfmR+srIAQz5FpmaSHcHrlD8YJhH/t8t4elRXHFUwLfbg0 kE+oARQMiNDnrnUUgHPNSaMQs/OVxyOd9nVOP/245WDn7EE9SPkBhUbVqEeMni1RK8 Zs5EWKY2DTZlbX8uqJLX3MNmFVZc6tg0sqKjE/+4= From: Andrew Sullivan To: iasa20@ietf.org Message-ID: <20171108225404.n3uk5wt4dprpmehw@mx4.yitter.info> References: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info> <28976c5c-9307-9079-9eb1-f7c791c16a89@gmail.com> <20171108221600.twlrk776mfjcciiw@mx4.yitter.info> <586088eb-2ebe-f590-d351-7bbf415d42bd@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <586088eb-2ebe-f590-d351-7bbf415d42bd@gmail.com> Archived-At: Subject: Re: [Iasa20] Some comments on draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:54:08 -0000 On Thu, Nov 09, 2017 at 11:26:46AM +1300, Brian E Carpenter wrote: > > We disagree. Let's hear from everybody else instead of repeating > ourselves. As long as we've figured out that we just disagree about this, yes :) A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 8 14:57:34 2017 Return-Path: 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 738D0126C22 for ; Wed, 8 Nov 2017 14:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 r8di5gb_TU0A for ; Wed, 8 Nov 2017 14:57:31 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9E27124B0A for ; Wed, 8 Nov 2017 14:57:31 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id i5so2823464pfe.6 for ; Wed, 08 Nov 2017 14:57:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kUpJg5gdtf/Geq3ef+zQ58jmIxNUR99hyX+FVYtgTHI=; b=n4Ck12fa0en365UVXlvmsk7q+DZ8qFy7b6YQhI/1vXx83cpC+Wh6XyyOrovgn5MH4k eL8vTi8rZRvJk4YNVo2jYrY1Thl7LPwQgPRGFMAAUsD7SdjbaPVSV7WsYmc4jS8Q468t +jyfsYYfSOXSyXlZ0+VkON4Be+K+d7gQ4+7nk6aZP11J38hc2JuNFUGNWYFMPAW0jeX6 h2pS0IyxSMpOvvsqV5ndN1EQP7H5rQtsnnjIdIrQDis+dFKDS8Uoq8WfsxaCOsZeFh48 imkaKpFDxQBnf+dMk7kBDEz5ekCz+0lfbiX7/RQeEtL7iDpKxkQLySRhNr5TGGDbA95g eLIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=kUpJg5gdtf/Geq3ef+zQ58jmIxNUR99hyX+FVYtgTHI=; b=heqhv5TJ4X9dghvoJCRTVFm0ZG6uZScoYkcQ2U95eQnL7rikxxbxRoh1njQpXrMfyU gy9xBEtyW6rlK92z3Bfl6GytthUbJFK7YjYnNB5/E5ySmR84HdyDSJMHHjJ7xfxiRG+D OuOEL2cuzZTsvNWQfciEuZU0HIZdEuR4pAify+9+2eNfm/wuSKdzsWWa5eYurW5eX1vW yeCrmzJl+lkq41kNc4+Q/ulNdw5lcmZYCf2Kh7m692zo49EQFFvPCrjv7U5JwXLXRwxU NyRpv+UADqlSm78VFJPi7nr6yP/lH349bEYXBzXoivVRLWFse9CnoZDBVyomDyXezX3j bPGQ== X-Gm-Message-State: AJaThX6RfaXlyDxN4lzrT3i9NdLUppdSPXNNTe4vLz/MTYE5Kh4wKdj8 pd5QnlIBwgmGheSzbO2aGjA= X-Google-Smtp-Source: ABhQp+StBl3eHia6Jmy2AXSKS5lcFwpFYcYhTbiJK8ZQRxMUyZ137eINMggVUYb1B+8W3VeGG51rpA== X-Received: by 10.84.236.70 with SMTP id h6mr1792348pln.166.1510181851308; Wed, 08 Nov 2017 14:57:31 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id 15sm9989919pfs.125.2017.11.08.14.57.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 14:57:30 -0800 (PST) From: Bob Hinden Message-Id: <6BD08845-E182-47A4-9332-7A3FD1199D69@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_DB343AAA-AF27-4B56-BF89-EDEF7EA47E64"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 8 Nov 2017 14:57:28 -0800 In-Reply-To: <20171108224924.beyzd6zmc3wsqj3j@mx4.yitter.info> Cc: Bob Hinden , iasa20@ietf.org To: Andrew Sullivan References: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> <6B399B19-037A-4F59-A35C-73FEF074F7C1@gmail.com> <20171108214708.3twjdffmjhknqarz@mx4.yitter.info> <20D7C285-1152-4275-831F-7DA7AAC19902@gmail.com> <20171108224924.beyzd6zmc3wsqj3j@mx4.yitter.info> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 22:57:33 -0000 --Apple-Mail=_DB343AAA-AF27-4B56-BF89-EDEF7EA47E64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Andrew, > On Nov 8, 2017, at 2:49 PM, Andrew Sullivan = wrote: >=20 > On Wed, Nov 08, 2017 at 02:12:51PM -0800, Bob Hinden wrote: >>=20 >> How is that going to be different if ISOC is still providing most of = the funding for the IETF? It=E2=80=99s not going to be hidden. >>=20 >=20 > If you give money today to an ISOC fund that has a red "IETF" in magic > marker on the outside, from the point of view of money people you have > given the money _to_ ISOC, but with the intention that they spend it > on the IETF. If they don't, then you might have had a reasonable > expectation not met and you might have a legal claim, but ISOC didn't > steal the money. I should have been clearer. My point is that if people see that ISOC is = still giving a lot of money to the IETF, they will ask the questions = like why isn=E2=80=99t ISOC giving more, I already give to ISOC, etc. = Unless we stop taking any significant amount of money from ISOC, I = don=E2=80=99t think this problem will go away. It=E2=80=99s not really = about bank accounts. Bob >=20 > If you given money to some future legally-incorporated entity called > "IETF" and that entity has a bank account, then if ISOC winds up the > IETF entity there are rules about what it can do with the IETF money, > because it is not just the same as any other money ISOC has. >=20 >> =46rom the POV of outsiders, the second of these is trivial to = explain > and the first is a pitch that has lost them by the time you got to > sentence two. >=20 >> Of course, some time people raise issue like this as a nicer way of = saying no. >=20 > There are lots of reasons people might do that. But I want to make > their job of selling us to their boards easier, not harder, and IASA++ > does not make it easier. >=20 > Best regards, >=20 > A >=20 > -- > Andrew Sullivan > ajs@anvilwalrusden.com >=20 > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 --Apple-Mail=_DB343AAA-AF27-4B56-BF89-EDEF7EA47E64 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloDi9gACgkQrut0EXfn u6hO1Af+PpGbRXOT3oWHnvX2CIOHJhu6NIAAY8+7/1KJFSIZvv5J/QFPDzENMqYZ fxe+dr9mPUUMkynzDLc5V/BjcQpEmea7kHa/47ErpDh3QfK7sZyNKt2Lj9A8Azw7 8HylKuAN/F6svzxje2LFF1xriA17oWaa1E73eWUu8vNyDFG2DwfvLG+j4vIh934s wzx6IQtJov9C3e33Y6U5OkvTZT/ds4KTjcXi2X8xt3TPhRmN/qpyge3bZM7h1Ayb CIj3nmuHAu0Ifo+DJE7+mGbx4V8Z2CkQG77nhhfrrLLXVvH0N1WMZ8QQ7iR5CQod Wl2hzWlhvGRt7iIz8s3sHwhE4Ja1pQ== =5K+R -----END PGP SIGNATURE----- --Apple-Mail=_DB343AAA-AF27-4B56-BF89-EDEF7EA47E64-- From nobody Wed Nov 8 15:03:24 2017 Return-Path: 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 EC4D7126E7A for ; Wed, 8 Nov 2017 15:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=kpkXzsLr; dkim=pass (1024-bit key) header.d=yitter.info header.b=EsDjigFX 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 2wUmFm2mvKAD for ; Wed, 8 Nov 2017 15:03:21 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84F1126D46 for ; Wed, 8 Nov 2017 15:03:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 06E3BBF56B for ; Wed, 8 Nov 2017 23:02:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510182171; bh=M5ZIUMRIX3zuyvH6dsmTfeOI1stgyB4TbuoRZGJmPkw=; h=Date:From:To:Subject:References:In-Reply-To:From; b=kpkXzsLrVYeRXOVE+8uvpnYZgFRg++EMONleNjb+DPBBjssaAlBeer5ukYzKv8SFx Dpg9wahLEuORjorcLRA/X9cbKU1caRixpejP0rUuAwHfqk/ViG3p2tsDAlMdjZcJjt H3NXxg7fmwUJEpVesaRF/gxNU2mVQ13k6FMbczjo= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4NVcqI4HZj9 for ; Wed, 8 Nov 2017 23:02:50 +0000 (UTC) Date: Wed, 8 Nov 2017 18:02:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510182169; bh=M5ZIUMRIX3zuyvH6dsmTfeOI1stgyB4TbuoRZGJmPkw=; h=Date:From:To:Subject:References:In-Reply-To:From; b=EsDjigFX3tC/AFWhQfW9SMDw9DEal3+ugjnqgmdYKIrGYSE+lZAFvjrI9Cjg/FWEZ aPTDtYCuwZehvbn89ACtIoI9BdNfZEWwSWRzvY/nY2XSIkHWRNz8MItt5Y+tjD1FWd LszxfiOPxpQBY4RLs6IKypKfd1d2aso+AL65jly4= From: Andrew Sullivan To: iasa20@ietf.org Message-ID: <20171108230249.qlfej64pg4xqvsgs@mx4.yitter.info> References: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info> <28976c5c-9307-9079-9eb1-f7c791c16a89@gmail.com> <20171108221600.twlrk776mfjcciiw@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Iasa20] Some comments on draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 23:03:23 -0000 On Wed, Nov 08, 2017 at 02:47:43PM -0800, Ted Hardie wrote: > our current circumstances. The IETF is an activity of ISOC. If the IETF > has control over anything, ISOC has control over it. We are part of ISOC. Correct for certain today, and possibly correct for the potential subsidiary arrangement of the future. > IASA++: Reorganize ISOC so that the IETF line of business can operate > differently within ISOC, in line with the needs identified. Yes, but as I noted in what I wrote originally upthread, this is at odds with the sentence in the draft about the IETF needing to make decisions independent of ISOC. We might not accept that claim, in which case the argument I made does not follow. But if we accept it, I cannot see how this approach meets the goals. > Subsidiary: Reorganize ISOC so that the IETF line of business is in a > distinct subsidiary that can operate differently, much as PIR operates > differently from ISOC's core operations. I think the key thing about a subsidiary relationship, however, is that it does have an independent legal existence and therefore slightly different fiuciary duties. There is a nasty threat here, of course, which is the case where the subsidiary does not want to do what the parent organization wants. In commercial arrangements, of course, the parent board has the ability to replace the subsidiary board and therefore to fix the conflict. I was assuming that such an arrangement would not be acceptable to the IETF community, but I might be wrong about that, so I ought to make the assumption explicit. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 8 15:40:40 2017 Return-Path: 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 E39EF12762F for ; Wed, 8 Nov 2017 15:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=b+QVY/r+; dkim=pass (1024-bit key) header.d=yitter.info header.b=SwBFrFmH 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 ckvDJyOc4W26 for ; Wed, 8 Nov 2017 15:40:38 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ACE9127419 for ; Wed, 8 Nov 2017 15:40:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 01307BF56B for ; Wed, 8 Nov 2017 23:40:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510184438; bh=r4AoiYXVJ30qr281dxHzIIStpMmccbqm1Xk8U2EngtY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=b+QVY/r+V6ETLm/4lIIyerm2ztj3p8T5/eVr1d9+on+7pznaV1svi65BrgXPT5eru 5ZjDOHWXJK7e5npDNyDSsd4jqFW6QF68BVwphD4XYgqMGe4a0O30P6xKnEMI8iwq2R XatXOlTe1vOBqDICDkQ5AMX6xJ9SKYl+AlrWtv4A= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdosUCiSO-tT for ; Wed, 8 Nov 2017 23:40:36 +0000 (UTC) Date: Wed, 8 Nov 2017 18:40:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510184436; bh=r4AoiYXVJ30qr281dxHzIIStpMmccbqm1Xk8U2EngtY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=SwBFrFmHbbbCABd3Hh8N/bpG/uOX5MNbZZWlt8GuUKA6XitTRtCdpk45h5O7HZBDU +m1tYp1hniBx9IG+Yob5aaVizn1d/NJ12ymIyYPE6XTHbOw8SK23kc7tXkNA8x/eBN 9c7P0pIgZJwlXP4IkZbm4ldF47UEUckdJhDcY+10= From: Andrew Sullivan To: iasa20@ietf.org Message-ID: <20171108234033.64iby5ajlcl7ciid@mx4.yitter.info> References: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> <6B399B19-037A-4F59-A35C-73FEF074F7C1@gmail.com> <20171108214708.3twjdffmjhknqarz@mx4.yitter.info> <20D7C285-1152-4275-831F-7DA7AAC19902@gmail.com> <20171108224924.beyzd6zmc3wsqj3j@mx4.yitter.info> <6BD08845-E182-47A4-9332-7A3FD1199D69@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6BD08845-E182-47A4-9332-7A3FD1199D69@gmail.com> Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 23:40:40 -0000 On Wed, Nov 08, 2017 at 02:57:28PM -0800, Bob Hinden wrote: > I should have been clearer. My point is that if people see that ISOC is still giving a lot of money to the IETF, they will ask the questions like why isn’t ISOC giving more, I already give to ISOC, etc. > Well, yes, but there's a faint circularity in that, I think. For presumably, if we are successfully raising money into an independent IETF fund, it is because we have a clear and compelling plan about how the funds will flow in the future. Separating the control is necessary but not sufficient. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Nov 8 17:05:26 2017 Return-Path: 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 10E5E129478 for ; Wed, 8 Nov 2017 17:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3TjC8aEz0gRb for ; Wed, 8 Nov 2017 17:05:21 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D1E129454 for ; Wed, 8 Nov 2017 17:05:21 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id a192so3336646pge.9 for ; Wed, 08 Nov 2017 17:05:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Nn8bdhvilHRhSWabozbNelq6jQ/kPZUTKLXbZ9DE7BU=; b=HBvNgRLoCyNuHcrUrd+mSrStuAmgQRhQ+pil3LY+5iSAW25RZ2LUy9n0PLY1g5qy3N P43uv5exeOr7BDKp9SFRJGLs8KJTAXWHalBXfWyijqjFcwDvuacKKWsTEBPK5qcxGwes PqEUsGI+zqtqRDsvHvfUlgN2vYlDvWQX4bHY6Va9m82VpEwkGOZplOghAYpkUhzUA+ld Qvfe1xR87XqjPTgfgoeb4WVZ4Z8v51bjGaUPSkrNNsCzYIWDGZ6f1SLD2oHkH68+IEXW 1M+UyZgvlQKYSeDNOIs5/bvqYuqeQk0I/VxsBfgLxKUbz02V/kRUlpdU3udP8q3jMpbI yZrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Nn8bdhvilHRhSWabozbNelq6jQ/kPZUTKLXbZ9DE7BU=; b=eBR/8WRkPl2lB/k6cEwrFgTwjoZHNAeIkiHpTKCzaD4FQMXSSD5lAEPbAfCKA0/hSE 1PLoGKMzsA1e+avQ9H34Ef+a8OF4jsWfUDWTPbfEl3WgOy/EeljtC4//qMJHGHiIp+go +ekHd7TdAniCAkCOnKAWEjoSxhM9JbfqiXYndL3MFibAAgTFueKJKfKXgCN6LMSZmWL8 aot+ol80r/oiQGDq9rgImcRLSAsvrm87ZRxk5MJDSyzzHe/BSzoUVnYaJ7H9tP3P/Cdx X4MGEWN0dl82G73203qEmWye8SqhWoixzvFunPNQIKF9xRDXpw7elPK/wXhLp+GUEDHn iXaA== X-Gm-Message-State: AJaThX4hZxBQvzDNkgPAVo49vBV84dbaZPqyVAYYv/uQLmFTZIrTuUgR ZgNodm+HIimPkwFZDzqQuyz0yg== X-Google-Smtp-Source: ABhQp+TsX3an/DT684kB/JHa+UOpd10I2wITomRWgwXIpaElo3Nqk9hRZ34jiunyC8fw0wxdUXj9TA== X-Received: by 10.159.244.148 with SMTP id y20mr2095466plr.282.1510189520910; Wed, 08 Nov 2017 17:05:20 -0800 (PST) Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id y5sm9930080pfk.3.2017.11.08.17.05.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 17:05:19 -0800 (PST) To: iasa20@ietf.org References: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info> <2EAB39A6-4532-4DFA-B713-DBD0D2355D81@gmail.com> <20171108221248.46uzlh5quzbflbwy@mx4.yitter.info> <7097F0F4-59B0-44F6-B1B6-7CB60C0CBFCA@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <008504d5-024d-ee1c-a1b2-5379c6ee6af5@gmail.com> Date: Thu, 9 Nov 2017 14:05:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Iasa20] Some comments on draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 01:05:24 -0000 On 09/11/2017 11:23, Richard Barnes wrote: > "In practice" is not really what matters here. It's all that matters. ISOC has the money, so if we don't trust them we are sunk anyway. Brian From nobody Wed Nov 8 21:07:50 2017 Return-Path: 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 6C63212EAFC for ; Wed, 8 Nov 2017 21:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 f60XsmZkGRbp for ; Wed, 8 Nov 2017 21:07:46 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFB541242EA for ; Wed, 8 Nov 2017 21:07:45 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id n74so778650wmi.1 for ; Wed, 08 Nov 2017 21:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jRyXtoefCsnBxZWqrzgkU2toI8gPNEffQyWAQBU3vf8=; b=mch0SjHyGXYI9q0CcJG7KxKjkpHAAERR2En+Idgp/v7rvpgEK8YK043095CCzW714U yn49At0kWYjsflnDRdZVCAKDm8AULEBNWpMpY8RGV+FWwFH59PISEEIBfyFmk2W849rs QavMQvFV68Ji7yPaM6tRXeDIzopjvlpxCh3glpo3POrsQvuQG4+syHJNdwys9lBinePl cjVIy3iSU4yLpIiCxC/6Y7gdS3PLBXULiuOL9uu4+2POwr6jBD3fHbygDviscefOG2CZ K1MgyO5yYY6PiKJDAEdu3RamGboLjatDPMlyOd9bHomgnxM4uaKu85d4Yuv5IyDCcxj+ JC7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=jRyXtoefCsnBxZWqrzgkU2toI8gPNEffQyWAQBU3vf8=; b=BLEPQZbM2843rfWnOvRZqxr2+R7sowdrBOT3Gohs3EYq7+L39AxntyUIBbzNdms6Cu SuXy9cCmXb10SaguZMh3JXazBlQ2zhRduo+G6sNZctqhKzBZishxy9SToYIkkr0I9nvP bvAjw1LBAWge+SMPUHXkNUc2CIf18EQauuABxOFa67oDbXtBm/IZxSGkVmbVHp7QFSmy DrM3Y63tMDWj761qUSZpjj/V4xs5dPHVKpcF0Jqlr2uJ5feIKj7Oewi1ySh8mUxhnZip T5E+IG4Grq2RWGBc4BJRsqZFe0QHUJHPO2PSKC/APx2rDXz2to+S8t4ZTIwPHr6qrwe1 /4vw== X-Gm-Message-State: AJaThX72hZujID6M7h9vO9v3kknbeOOJe91t2wzpSxXi0ni/X1MbJq37 GipfU4spyJHqOzxu/QvEmvX4Nn9o X-Google-Smtp-Source: ABhQp+QOXRsgizfEaljC839GnbJecwHlxEk059iMHNlp6DWk258ij3rdYGDHGPAO8ANf6De+v/A8lA== X-Received: by 10.80.173.210 with SMTP id b18mr3790804edd.148.1510204064198; Wed, 08 Nov 2017 21:07:44 -0800 (PST) Received: from ?IPv6:2601:647:4d01:db10:c8ea:8433:8cb9:4b51? ([2601:647:4d01:db10:c8ea:8433:8cb9:4b51]) by smtp.gmail.com with ESMTPSA id f27sm4707554edj.82.2017.11.08.21.07.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 21:07:43 -0800 (PST) From: Bob Hinden Message-Id: <279F6333-07F1-40B7-86B2-4D266A48803C@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_C4AE4CF8-F950-4F81-9474-4D73514E456F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 8 Nov 2017 21:07:40 -0800 In-Reply-To: <20171108234033.64iby5ajlcl7ciid@mx4.yitter.info> Cc: Bob Hinden , iasa20@ietf.org To: Andrew Sullivan References: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> <6B399B19-037A-4F59-A35C-73FEF074F7C1@gmail.com> <20171108214708.3twjdffmjhknqarz@mx4.yitter.info> <20D7C285-1152-4275-831F-7DA7AAC19902@gmail.com> <20171108224924.beyzd6zmc3wsqj3j@mx4.yitter.info> <6BD08845-E182-47A4-9332-7A3FD1199D69@gmail.com> <20171108234033.64iby5ajlcl7ciid@mx4.yitter.info> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 05:07:48 -0000 --Apple-Mail=_C4AE4CF8-F950-4F81-9474-4D73514E456F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Andrew, > On Nov 8, 2017, at 3:40 PM, Andrew Sullivan = wrote: >=20 > On Wed, Nov 08, 2017 at 02:57:28PM -0800, Bob Hinden wrote: >=20 >> I should have been clearer. My point is that if people see that ISOC = is still giving a lot of money to the IETF, they will ask the questions = like why isn=E2=80=99t ISOC giving more, I already give to ISOC, etc. >>=20 >=20 > Well, yes, but there's a faint circularity in that, I think. For > presumably, if we are successfully raising money into an independent > IETF fund, it is because we have a clear and compelling plan about how > the funds will flow in the future. Separating the control is > necessary but not sufficient. Agree. The hard parts are telling potential donors what the value is = and what the IETF wants to do in the future it isn=E2=80=99t doing now. Thanks, Bob --Apple-Mail=_C4AE4CF8-F950-4F81-9474-4D73514E456F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloD4pwACgkQrut0EXfn u6gcoAf+NmoWg27iwiX8ynfzdfnf/GAiTLG1tQlJO1HaZBbIWk5qC8+ye1MpGkhK b+2IYEgrspy1MTeoC+ECDhj7cj6WNJuQckCNa+iMTGiuyk8R+2sFxS6iRqFsdABu tSv7iK/IYkH8U1CG7RGIPIFHBLyIMwOUR3n7tjLPwwrHJpKzSDy3KvgwuBOdBGpI wvgZ7YLgJqKi8YS9UUdqBzJw+zLj2Zv2M+TwnNBovXx30DcN8Tfh01A9ivHBZOXX G9U4LgppKoFNT7UjbuzMwOZKaCjYMnc2gkOnLERDewC7mS88mp7m5ZKA2x3iI9nA 8HkEdjzHCOKUjZ5iBJztunrFNeOHgg== =0Vbb -----END PGP SIGNATURE----- --Apple-Mail=_C4AE4CF8-F950-4F81-9474-4D73514E456F-- From nobody Thu Nov 9 03:07:27 2017 Return-Path: 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 04AA012ECC2 for ; Thu, 9 Nov 2017 03:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 HbJvm-FXv0L3 for ; Thu, 9 Nov 2017 03:07:24 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC98F12EC8E for ; Thu, 9 Nov 2017 03:07:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14556; q=dns/txt; s=iport; t=1510225643; x=1511435243; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ItWOePH43VIxEgXdZcd9RQr3U3Ug1a4KdpH5K6PlwW8=; b=Ckk0O35gqE2ZhdUEsiwFRd9/2N108WbiTkmBvob4vOYScaggT4sg85IE kvelCR8ilxBNyGUbwAUmxFcI2bva1jtQWz7HroBWRQYmsahcWQ3VBwmV8 IaLrAxmbB0QqhtKfI0GozB73mqEi1ugQZaURHx5MNQNMSouJpd9h3eIg7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CkAAAeNQRa/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJEcGRuJweDdoofjyeBfJEFhUiCEQojhRgCGoQoPxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUeAQEBAQMjCkQYAgEIEQMBAisCAgIwHQgCBAESFIkrZBCpP4InJopvA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDMIIHgz0pgXSBDYU2gnUxgjIFohoCh2W?= =?us-ascii?q?NF5M4jGiJDAIRGQGBOAEfOIFxehVJLQGCNoRfd4p5gREBAQE?= X-IronPort-AV: E=Sophos;i="5.44,369,1505779200"; d="scan'208,217";a="100480237" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2017 11:05:21 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vA9B5LQA018343 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Nov 2017 11:05:21 GMT Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 9 Nov 2017 05:05:21 -0600 Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1320.000; Thu, 9 Nov 2017 05:05:21 -0600 From: "Charles Eckel (eckelcu)" To: Jari Arkko , "iasa20@ietf.org" Thread-Topic: [Iasa20] Thank you & we need your feedback Thread-Index: AQHTUzqAbrJO46H9VEiBhc2ZVJmUMaML/+SA Date: Thu, 9 Nov 2017 11:05:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.66.255.86] Content-Type: multipart/alternative; boundary="_000_DC810D1F901F43D5A1F92DD18BCCCB9Eciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 11:07:26 -0000 --_000_DC810D1F901F43D5A1F92DD18BCCCB9Eciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIHRvIGV2ZXJ5b25lIGludm9sdmVkIGluIHB1dHRpbmcgdGhpcyBkcmFmdCB0b2dldGhl ci4gSXQgaXMgb2J2aW91cyBhIGdyZWF0IGRlYWwgb2YgdGltZSBhbmQgdGhvdWdodCB3ZW50IGlu dG8gaXQuIE9uIHRoZSBsb25nIGZsaWdodCB0byBTaW5nYXBvcmUgd2l0aG91dCBXaUZpLCBJIGFt IHJlYWRpbmcgaXQgYWxvbmcgd2l0aCB0aGUgaW5zaWdodGZ1bCBhbmQgdGhvdWdodCBwcm92b2tp bmcgY29tbWVudHMgb3RoZXJzIGhhdmUgYWxyZWFkeSBwcm92aWRlZC4NCkkgdGhvdWdodCBJ4oCZ ZCBzaGFyZSBhIGZldyBvcGluaW9ucyBJIGZvcm1lZCB3aGlsZSB0cnlpbmcgdG8gZGlnZXN0IGFs bCBvZiB0aGlzLiBJIGhvcGUgdGhleSBhcmUgdXNlZnVsLg0KDQoqIFdpdGggZ3JlYXRlciBpbmRl cGVuZGVuY2UgY29tZXMgZ3JlYXRlciBjb3N0LCBjb3N0cyBjb3ZlcmVkIGJ5IElTT0MsIHdoaWNo IGlzIGludGVyZXN0aW5nIGJ1dCBwZXJoYXBzIGEgZ29vZCB0aGluZywgYmVjYXVzZSBJU09DIG5l ZWRzIHRvIGJlbGlldmUgaW4gYW5kIGFwcHJvdmUgb2YgdGhpcyBwbGFuLiBJbiB0aGlzIHNlbnNl LCBJQVNBKysgc2VlbXMgYmVzdCB0byBtZSwgYnV0IHRoYXQgaXMgd2l0aCB0aGUgYmlnIGFzc3Vt cHRpb24gd2UgYXJlIGFibGUgdG8gY29uc3RydWN0IGl0IHN1Y2ggdGhhdCBpdCBwcm92aWRlcyB0 aGUgaW5kZXBlbmRlbmNlIGFuZCBiZW5lZml0cyBlbnZpc2lvbmVkIHdpdGggdGhlIG90aGVyIG9w dGlvbnMuIElmIG5vdCwgdGhlbiB0aGUgc3Vic2lkaWFyeSBtb2RlbCBzZWVtcyBuZWNlc3Nhcnkg YW5kIGJlc3QuIENvbXBsZXRlIGluZGVwZW5kZW5jZSBpbiBhbGwgd2F5cyBmcm9tIElTT0MgaXMg bm90IGRlc2lyZWQsIGJ1dCBpbmRlcGVuZGVuY2UgaW4gc29tZSB0aGluZ3MgdGhhdCBJU09DIGFn cmVlcyB0byBoYXZlIGluZGVwZW5kZW50IGlzIGEgcmVhbGx5IGdvb2QgdGhpbmcuIEkgcmVhbGl6 ZSB0aGlzIGlzIGNpcmN1bGFyLCBidXQgYXMgSSB1bmRlcnN0YW5kIGl0LCBtdWNoIG9mIHRoZSBt b25leSBjb250aW51ZXMgdG8gY29tZSBmcm9tIElTT0Mgd2l0aCBhbGwgdGhyZWUgbW9kZWxzLCBz byBJU09DIG5lZWRzIHRvIGJlIG9uIGJvYXJkLg0KDQoqIE5vbUNvbSwgYXMgaXMgZXhpc3RzIHRv ZGF5LCBpcyBub3QgbGlrZWx5IHRvIGJlIGluIGEgZ29vZCBwb3NpdGlvbiB0byBkZXRlcm1pbmUg SUFPQy9Cb2FyZCBtYWtldXANCg0KKiBTcG9uc29yc2hpcCBhbmQgYnVkZ2V0aW5nL2Zpc2NhbCBy ZXNwb25zaWJpbGl0eSBzdWZmZXJzIGZyb20gYSBtb2RlbCBpbiB3aGljaCBJU09DIGNvdmVyIHNo b3J0YWdlcy4gQSBsYXJnZXIsIHVwZnJvbnQgYW5udWFsIGJ1ZGdldCBmcm9tIElTT0Mgd2l0aCBn cmVhdGVyIGZpc2NhbCBhY2NvdW50YWJpbGl0eSBieSB0aGUgSUVURiB3b3VsZCBiZSBiZXR0ZXIN Cg0KKiBTdGFmZiBhbmQgYm9hcmQgYWNjb3VudGFibGUgdG8gSUVURiBzZWVtcyBuZWNlc3NhcnkN Cg0KKiBUaGUgc2tpbGxzZXQgZm9yIHRoZSBkaXJlY3RvciBhbmQgZnVuZHJhaXNlciBhbmQgdGhl IGRpcmVjdG9yIG9mIGNvbW11bmljYXRpb25zIHNlZW1zIHByZXR0eSBzaW1pbGFyIHRvIG1lLiBC b3RoIGFyZSBwcmltYXJpbHkgb3V0d2FyZCBmb2N1c2VkIGdldHRpbmcgdGhlIHdvcmQgb3V0IGFi b3V0IElFVEYgYWN0aXZpdGllcyBhbmQgYWNjb21wbGlzaG1lbnRzIGFuZCBwdXR0aW5nIHRoZW0g aW4gYSBnb29kIGxpZ2h0IHRoYXQgYXR0cmFjdHMgbWVtYmVycywgcGFydG5lcnMsIHNwb25zb3Jz LCBldGMuIENvbWJpbmluZyB0aGVtIGludG8gYSBzaW5nbGUgcG9zaXRpb24gbWlnaHQgYmUgYSBn b29kIG9wdGlvbi4NCg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQpGcm9tOiBpYXNhMjAgPGlhc2EyMC1i b3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVo YS5uZXQ+DQpEYXRlOiBUaHVyc2RheSwgTm92ZW1iZXIgMiwgMjAxNyBhdCAxOjU0IEFNDQpUbzog Imlhc2EyMEBpZXRmLm9yZyIgPGlhc2EyMEBpZXRmLm9yZz4NClN1YmplY3Q6IFtJYXNhMjBdIFRo YW5rIHlvdSAmIHdlIG5lZWQgeW91ciBmZWVkYmFjaw0KDQpUaGFuayB5b3UgZm9yIHRoZSBmZWVk YmFjayB3ZeKAmXZlIHJlY2VpdmVkIHNvIGZhciAoaW5jbC4gc29tZSBvZmYtbGlzdCkuIE11Y2gg YXBwcmVjaWF0ZWQsIGFuZCB3ZSBhcmUgbG9va2luZyBhdCBpdCBjYXJlZnVsbHkuDQoNCkkgd291 bGQgbGlrZSB0byBhc2sgZm9yIG1vcmUgcGVvcGxlIHRvIGxvb2sgYXQgdGhlIGRvY3VtZW50LCBh bmQgZG8gc28gZXZlbiBiZWZvcmUgdGhlIG1lZXRpbmcsIGhlcmUgb24gdGhpcyBsaXN0LiBJIGJl bGlldmUgQWxpc3Nh4oCZcyBwbGFuIGlzIHRvIGNvbWUgb3V0IG9mIFNpbmdhcG9yZSB3aXRoIGEg c2Vuc2Ugb2YgdGhlIGNvbW11bml0eSBvbiB3aGljaCBkaXJlY3Rpb24gdG8gcHVyc3VlLCBhbmQg dGhhdCBjYW4gYmUgYmVzdCBhY2hpZXZlZCBpZiBhdCBsZWFzdCBzb21lIG9mIHRoZSBzdWJzdGFu dGl2ZSBkaXNjdXNzaW9uIGNhbiBoYXBwZW4gYmVmb3JlIG91ciBtZWV0aW5nLCBhbmQgd2UgY2Fu IGJldHRlciBwcmVwYXJlIGZvciB0aGUgcXVlc3Rpb25zIGFuZCBpZGVhcyBwZW9wbGUgd2lsbCBo YXZlLg0KDQpUaGUgZG9jdW1lbnQgaXMgaGVyZToNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWhhYmVybWFuLWlhc2EyMGR0LXJlY3MtMDENCg0KSmFyaSBmb3IgdGhlIGRlc2ln biB0ZWFtDQoNCg== --_000_DC810D1F901F43D5A1F92DD18BCCCB9Eciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <5F0E0FA0F5385345A41478716224C5A8@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtY29tcG9zZTsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29s b3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNyIvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPlRo YW5rcyB0byBldmVyeW9uZSBpbnZvbHZlZCBpbiBwdXR0aW5nIHRoaXMgZHJhZnQgdG9nZXRoZXIu IEl0IGlzIG9idmlvdXMgYSBncmVhdCBkZWFsIG9mIHRpbWUgYW5kIHRob3VnaHQgd2VudCBpbnRv IGl0LiBPbiB0aGUgbG9uZyBmbGlnaHQgdG8gU2luZ2Fwb3JlIHdpdGhvdXQgV2lGaSwgSQ0KIGFt IHJlYWRpbmcgaXQgYWxvbmcgd2l0aCB0aGUgaW5zaWdodGZ1bCBhbmQgdGhvdWdodCBwcm92b2tp bmcgY29tbWVudHMgb3RoZXJzIGhhdmUgYWxyZWFkeSBwcm92aWRlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkkgdGhvdWdo dCBJ4oCZZCBzaGFyZSBhIGZldyBvcGluaW9ucyBJIGZvcm1lZCB3aGlsZSB0cnlpbmcgdG8gZGln ZXN0IGFsbCBvZiB0aGlzLiBJIGhvcGUgdGhleSBhcmUgdXNlZnVsLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj4qIFdpdGggZ3JlYXRlciBpbmRlcGVuZGVuY2UgY29tZXMgZ3JlYXRlciBjb3N0LCBjb3N0 cyBjb3ZlcmVkIGJ5IElTT0MsIHdoaWNoIGlzIGludGVyZXN0aW5nIGJ1dCBwZXJoYXBzIGEgZ29v ZCB0aGluZywgYmVjYXVzZSBJU09DIG5lZWRzIHRvIGJlbGlldmUgaW4gYW5kIGFwcHJvdmUgb2Yg dGhpcw0KIHBsYW4uIEluIHRoaXMgc2Vuc2UsIElBU0EmIzQzOyYjNDM7IHNlZW1zIGJlc3QgdG8g bWUsIGJ1dCB0aGF0IGlzIHdpdGggdGhlIGJpZyBhc3N1bXB0aW9uIHdlIGFyZSBhYmxlIHRvIGNv bnN0cnVjdCBpdCBzdWNoIHRoYXQgaXQgcHJvdmlkZXMgdGhlIGluZGVwZW5kZW5jZSBhbmQgYmVu ZWZpdHMgZW52aXNpb25lZCB3aXRoIHRoZSBvdGhlciBvcHRpb25zLiBJZiBub3QsIHRoZW4gdGhl IHN1YnNpZGlhcnkgbW9kZWwgc2VlbXMgbmVjZXNzYXJ5IGFuZCBiZXN0Lg0KIENvbXBsZXRlIGlu ZGVwZW5kZW5jZSBpbiBhbGwgd2F5cyBmcm9tIElTT0MgaXMgbm90IGRlc2lyZWQsIGJ1dCBpbmRl cGVuZGVuY2UgaW4gc29tZSB0aGluZ3MgdGhhdCBJU09DIGFncmVlcyB0byBoYXZlIGluZGVwZW5k ZW50IGlzIGEgcmVhbGx5IGdvb2QgdGhpbmcuIEkgcmVhbGl6ZSB0aGlzIGlzIGNpcmN1bGFyLCBi dXQgYXMgSSB1bmRlcnN0YW5kIGl0LCBtdWNoIG9mIHRoZSBtb25leSBjb250aW51ZXMgdG8gY29t ZSBmcm9tIElTT0Mgd2l0aA0KIGFsbCB0aHJlZSBtb2RlbHMsIHNvIElTT0MgbmVlZHMgdG8gYmUg b24gYm9hcmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiogTm9tQ29tLCBhcyBpcyBleGlzdHMgdG9k YXksIGlzIG5vdCBsaWtlbHkgdG8gYmUgaW4gYSBnb29kIHBvc2l0aW9uIHRvIGRldGVybWluZSBJ QU9DL0JvYXJkIG1ha2V1cDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4qIFNwb25zb3JzaGlwIGFuZCBi dWRnZXRpbmcvZmlzY2FsIHJlc3BvbnNpYmlsaXR5IHN1ZmZlcnMgZnJvbSBhIG1vZGVsIGluIHdo aWNoIElTT0MgY292ZXIgc2hvcnRhZ2VzLiBBIGxhcmdlciwgdXBmcm9udCBhbm51YWwgYnVkZ2V0 IGZyb20gSVNPQyB3aXRoIGdyZWF0ZXIgZmlzY2FsIGFjY291bnRhYmlsaXR5DQogYnkgdGhlIElF VEYgd291bGQgYmUgYmV0dGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiogU3RhZmYgYW5kIGJvYXJk IGFjY291bnRhYmxlIHRvIElFVEYgc2VlbXMgbmVjZXNzYXJ5PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi PiogVGhlIHNraWxsc2V0IGZvciB0aGUgZGlyZWN0b3IgYW5kIGZ1bmRyYWlzZXIgYW5kIHRoZSBk aXJlY3RvciBvZiBjb21tdW5pY2F0aW9ucyBzZWVtcyBwcmV0dHkgc2ltaWxhciB0byBtZS4gQm90 aCBhcmUgcHJpbWFyaWx5IG91dHdhcmQgZm9jdXNlZCBnZXR0aW5nIHRoZSB3b3JkIG91dCBhYm91 dA0KIElFVEYgYWN0aXZpdGllcyBhbmQgYWNjb21wbGlzaG1lbnRzIGFuZCBwdXR0aW5nIHRoZW0g aW4gYSBnb29kIGxpZ2h0IHRoYXQgYXR0cmFjdHMgbWVtYmVycywgcGFydG5lcnMsIHNwb25zb3Jz LCBldGMuIENvbWJpbmluZyB0aGVtIGludG8gYSBzaW5nbGUgcG9zaXRpb24gbWlnaHQgYmUgYSBn b29kIG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Q2hhcmxlczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPmlhc2EyMCAmbHQ7aWFzYTIwLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7 IG9uIGJlaGFsZiBvZiBKYXJpIEFya2tvICZsdDtqYXJpLmFya2tvQHBpdWhhLm5ldCZndDs8YnI+ DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIE5vdmVtYmVyIDIsIDIwMTcgYXQgMTo1NCBBTTxicj4N CjxiPlRvOiA8L2I+JnF1b3Q7aWFzYTIwQGlldGYub3JnJnF1b3Q7ICZsdDtpYXNhMjBAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltJYXNhMjBdIFRoYW5rIHlvdSAmYW1wOyB3ZSBu ZWVkIHlvdXIgZmVlZGJhY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IGZvciB0aGUgZmVlZGJhY2sgd2XigJl2ZSByZWNlaXZl ZCBzbyBmYXIgKGluY2wuIHNvbWUgb2ZmLWxpc3QpLiBNdWNoIGFwcHJlY2lhdGVkLCBhbmQgd2Ug YXJlIGxvb2tpbmcgYXQgaXQgY2FyZWZ1bGx5Lg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIGxpa2UgdG8gYXNrIGZvciBtb3JlIHBlb3BsZSB0 byBsb29rIGF0IHRoZSBkb2N1bWVudCwgYW5kIGRvIHNvIGV2ZW4gYmVmb3JlIHRoZSBtZWV0aW5n LCBoZXJlIG9uIHRoaXMgbGlzdC4gSSBiZWxpZXZlIEFsaXNzYeKAmXMgcGxhbiBpcyB0byBjb21l IG91dCBvZiBTaW5nYXBvcmUgd2l0aCBhIHNlbnNlIG9mIHRoZSBjb21tdW5pdHkgb24gd2hpY2gg ZGlyZWN0aW9uIHRvIHB1cnN1ZSwgYW5kIHRoYXQNCiBjYW4gYmUgYmVzdCBhY2hpZXZlZCBpZiBh dCBsZWFzdCBzb21lIG9mIHRoZSBzdWJzdGFudGl2ZSBkaXNjdXNzaW9uIGNhbiBoYXBwZW4gYmVm b3JlIG91ciBtZWV0aW5nLCBhbmQgd2UgY2FuIGJldHRlciBwcmVwYXJlIGZvciB0aGUgcXVlc3Rp b25zIGFuZCBpZGVhcyBwZW9wbGUgd2lsbCBoYXZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZG9jdW1lbnQgaXMgaGVyZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhYmVybWFuLWlhc2EyMGR0LXJlY3Mt MDEiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYWJlcm1hbi1pYXNhMjBkdC1y ZWNzLTAxPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5KYXJpIGZvciB0aGUgZGVzaWduIHRlYW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DC810D1F901F43D5A1F92DD18BCCCB9Eciscocom_-- From nobody Thu Nov 9 19:15:55 2017 Return-Path: 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 95E58128C82 for ; Thu, 9 Nov 2017 19:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=o5/E70Q7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PRGblq+u 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 xVRn88FPzCo8 for ; Thu, 9 Nov 2017 19:15:53 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0716F127977 for ; Thu, 9 Nov 2017 19:15:53 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6FBF820CC1; Thu, 9 Nov 2017 22:15:52 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 09 Nov 2017 22:15:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=QfrN4K5xPsZT7WF8wJhwgbRBUqfo2 WUp9nmqi2JSI3w=; b=o5/E70Q7gfjxav3D5dLSqvUWjEEnkL43e2VOUe5g+rk5M 5qO1ETyrLEaJZbtmN5U/DKOW8ls7B4k6/Fj34tR1vJmAa46qmqCJBsqxPKkJbXwE 0o/BNvko/UfkovxQyv7kZmHH49STPn9OneUfzePosVJLsm3Kb+tahXsEzwe4Urb4 fi3+IpwS62ftbvAZkrJ06Sy0HAU8i2u93xlfSQQWFRTLH5QqPCRxZ+UUenHtgtEF +i5UGOBnw6i4GOGj2b33Tez+jiAZfssNuoEtzL70FnkKUSP0jlsISJNXiAHNmWdS PBrya78zwzTtu3UdrEa79kUr9IqYzHRl1Fz+kymGQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=QfrN4K 5xPsZT7WF8wJhwgbRBUqfo2WUp9nmqi2JSI3w=; b=PRGblq+uZtYa75ydilkwlh 1PHwrxXaI+XgZqWauFSLaDTbX30mVq6+N6ZHP7UtwbN70uNdRyl3EXPWQ6TKx2z/ lqWNbweSgWWIMbnitCnSSmx4doeuDpYhRcWmNSYLgYiwwco/zG1JsmSiN7VdoqFU 808QPW55qI7YwoLQoWdfzVq+9AElEZHQyNcBGndfQZLFN5EEAQhscJqXPTbqtCRf cS4kUMWsuBUEKlU7ek0cWnjGXezm7pFm00TDjgifQ8HdoclkqPGk2nu+oFL1Wi/z yljC84QKWsxZgAiykwMHZzSd1Eb6qUvq0ObVGKezBwf5wAD3aoY5oBBPPvxZ69tg == X-ME-Sender: Received: from [10.24.6.172] (unknown [128.107.241.167]) by mail.messagingengine.com (Postfix) with ESMTPA id 43DCA7FADD; Thu, 9 Nov 2017 22:15:51 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Fri, 10 Nov 2017 11:15:48 +0800 Cc: iasa20@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8B56C5FB-2402-47AC-893A-891ACF53814B@cooperw.in> References: To: Bob Hinden X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Iasa20] Comments on X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 03:15:54 -0000 Hi Bob, > On Nov 8, 2017, at 8:51 AM, Bob Hinden wrote: >=20 > Hi, >=20 > Thanks for putting this together, I think it is an improvement over = the earlier version. >=20 > I have a lot of comments, but will stick with what I see is the high = level issue. >=20 > I think the basic conflict in the document is that it wants to not = make any change in how the IETF=E2=80=99s standardization works, but at = the same time wants to make the IETF more independent and in control of = what it does. I don=E2=80=99t think this is possible. We currently = have a model where financial decisions are kept very separate from the = standardization activities. When, for example, the IESG decides it = wants the IETF to do something it hasn=E2=80=99t done before, there is = never a discussion about how much does this cost and does it fit within = the budget. I use the IESG as an example, but it the same for the IAB, = IRTF, and RFC-Editor. =20 This doesn=E2=80=99t really match my experience. It=E2=80=99s true that = the budget is crafted and managed by different people than those who = make strategic decisions about standardization, architecture, and = research activities in the IETF/IRTF. But the IESG, and certainly the = IETF Chair, considers how much things cost all the time. For example, = last week I had a conversation with the secretariat about expenses = related to having multiple screens in the IETF meeting rooms. Within the = last couple of months the IESG had discussions about new MeetEcho = features we=E2=80=99d like to see, and the subject of cost came up both = in our conversation and as a gating factor requiring expenditure = approval before we could move forward. I personally think there are some = tools projects that I=E2=80=99d love to see done in the near term, but = since I know the tools budget is maxed out with the RFC format changes, = I haven=E2=80=99t initiated those conversations yet. Perhaps these are = smaller in value/cost than what you are thinking about (e.g., it=E2=80=99s= not like we cancel a meeting when we can=E2=80=99t find a host), but I = don=E2=80=99t think any of the leadership bodies operates as if there is = a bottomless well of money that can be spent if we so choose. It is of course true that we don=E2=80=99t take strict measures to stay = within the bounds of what we budget each year. But I think the IETF = leadership already takes costs into consideration more often than you = suggest. Alissa > We have the luxury of operating this way because we know that ISOC = will pick up the extra costs. To make a very rough analogy, we are the = teenagers still living at home, but wanting complete independence and a = bigger allowance. Are we willing to move out, get a job, pay for an = apartment, etc. and become independent of our parents? I read a lot of = things in this document wanting to have it both ways. >=20 > If we want to be more independent (especially in the Subsidiary and = Independent models), I think this way of operating will need to change. = The IETF will have to become like an conventional organization where = finance is part of most decisions. For example, if the IESG decides to = add a new area, add ADs, add working groups, new tools, have an interim = meeting, or something else, it will need to know this fits in the = current budget. The IESG will need to have a budget, and live within = it=E2=80=99s budget. It will need to make the tradeoff between = something new and stopping some existing activity, or defer the new work = until more funding can be found. The IETFAdminOrg (staff and board) = won=E2=80=99t be able to do this because they don=E2=80=99t have enough = information to make good tradeoffs. More importantly, we will get = better decisions by having the IESG making these decisions. >=20 > If we don=E2=80=99t do something like this where finance is part of = what the IESG, IAB, RFC-Editor, and IRTF do, I don=E2=80=99t think we = will be able to move away from model where ISOC is the financial = backstop with everything else that comes along with this. Otherwise = we will continue to live in the world where we pretend that money = doesn=E2=80=99t exist. We can=E2=80=99t really become independent if we = continue to live in this world. >=20 > I think this will be necessary if we want to become an ISOC Subsidiary = or Independent organization. If we don=E2=80=99t want to do this, then = we should focus on improving and clarifying our relationship with ISOC. = Something like the IASA++ model. >=20 > I am not against the IETF becoming an ISOC Subsidiary (complete = Independence is not practical as far as I can tell), but think we need = to be realistic about what it means to do this. I don=E2=80=99t think = the changes can be limited to a separate IETFAdminOrg if we want it to = work. >=20 > Thanks, > Bob >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 From nobody Thu Nov 9 19:27:06 2017 Return-Path: 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 E3C1A126E64 for ; Thu, 9 Nov 2017 19:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=szJKVlO1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XQYuIbEr 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 sAYbIj1ZYvLi for ; Thu, 9 Nov 2017 19:27:04 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CAC7124205 for ; Thu, 9 Nov 2017 19:27:04 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 8749C20E4D; Thu, 9 Nov 2017 22:27:03 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 09 Nov 2017 22:27:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=FTc5weZKL3xhoFN76G3bNwMjSf8KT 5VCdcptMBYqs0A=; b=szJKVlO1nLBfJ2OU87n3anO1Wa+LYWoDy70SKxtiCd59+ ykxjwgAOypr5OBX8dhJvWjHimaDeKWEh+6ukBEuHj6tRjb445d9w1QA5z6RneH+r 2dYyDXwKxNZVzVGx4yLcbLxQZi6lyooIZkRcq1wfWlqPMzRLllRJZeFNJG7Ka+lb TgRcyUaAiFOMaECoFEy9moQZFA/dbxwLKqP5XDywA7mXpA93FybTklIU9ITvwFlY hD61hyA7kTowbx/f4TH3FSa67pQBXygOS+xTxKWDy1Q3Q/u6e3Idpr68IoYgnKQV 8u/jvpG/tmCktpEbl25kF+YBYPfeSOjZsL1xCy+EA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=FTc5we ZKL3xhoFN76G3bNwMjSf8KT5VCdcptMBYqs0A=; b=XQYuIbEr/keyz72GdmPwm/ on5F5k53YcxvO0/cOvsVD1xW6fR1utveZN+i8zSOveQxkOcUCpbQ7bfrJiP9PYW9 LGipbvWk259/YykoQb8DylXZWtM6fOW6dAI9qjGC0PKy80kPnnt3gKZgt5eqHT6T hMz8chAlWL5SpRAGjR8QNxosn0TZ923mpGX5/XJsyXyTGFztmhrbxkJB1sS+wc+2 BXa/F2rLU9MRwyvTrUNr2Cf6BQrN0/ZF3BRAODy2RPfG+TY0FbYlNHzS7ZiXh6OF HEmG1JbU7LH1nXeXjlAS9+REh167sfcjKdRrANyxxyYrIC/G0mIUXbs7WhlcImcg == X-ME-Sender: Received: from [10.24.6.172] (unknown [128.107.241.167]) by mail.messagingengine.com (Postfix) with ESMTPA id 8EED47F8D8; Thu, 9 Nov 2017 22:27:02 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <2de8f0bd-6009-1375-c60d-4921a77e4d18@gmail.com> Date: Fri, 10 Nov 2017 11:26:59 +0800 Cc: iasa20@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <71989A13-2850-49A5-8553-2C231BFAE634@cooperw.in> References: <150826730924.11473.15624020870916138544@ietfa.amsl.com> <2de8f0bd-6009-1375-c60d-4921a77e4d18@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Iasa20] I-D Action: draft-haberman-iasa20dt-recs-01.txt X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 03:27:06 -0000 Hi Brian, I wanted to respond to a couple of your points in various mails to = provide some details of what I=E2=80=99ve observed lately. I will try = not to opine. :-) > On Nov 8, 2017, at 9:55 AM, Brian E Carpenter = wrote: >=20 > Hi, >=20 > Thanks for the work on this version. I find it much improved; my = comments > on the text follow. I'll send a separate message on my overall = opinion. >=20 >> 3.1.3. Authority > ... >> For example, due to IETF's lack of legal status, contractual >> agreements must be signed by ISOC on behalf of the IETF. There are >> occasions when a decision that is right for the IETF and desired by >> IETF leadership cannot be executed due to constraints posed by what >> ISOC can and cannot agree to itself. For example, when IETF sought >> to acquire a recent piece of software for business purposes, ISOC >> would initially not agree to entering into an agreement with the >> software provider. > Without asking for details, can somebody explain that a bit more? Was > it due to legal or financial doubts, or was there something else > going on? I=E2=80=99m aware of one recent example, although I=E2=80=99m not sure = if it=E2=80=99s the one referenced in the draft. In that case, the = objection had nothing to do with legal or financial doubts. ISOC staff = had used the software and didn=E2=80=99t like it, so objected to it = being used for IETF purposes. Alissa From nobody Thu Nov 9 19:38:26 2017 Return-Path: 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 3F393126E64 for ; Thu, 9 Nov 2017 19:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=MP2kfeQ1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GnR7PKBB 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 Tu2bZhBg2cQF for ; Thu, 9 Nov 2017 19:38:23 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DFF4124205 for ; Thu, 9 Nov 2017 19:38:23 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6FB09209B6; Thu, 9 Nov 2017 22:38:22 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 09 Nov 2017 22:38:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=GkSpyVk3xEIb62MAv2CZYEpBOtVmj7EIU28X5QIUI1U=; b=MP2kfeQ1 d9oC5Yt3J7yj/mtFXOt+cyBYafgH3eL4eSMA40Dd0f7m1N5jp/PDApeXI8tMQxe4 NEKlwtxKIZlgbtsRN/gOFsWVybY5JUoRqbWZGMPZYKhIwytqH4O9/phSsT+AzoiH ImUljnacOJ2XST6r3chJzQiKFiQv5xsorcOjvFXyD+3gLJLoSEo+Sjn+HMGOkbcp gjrC4cf949fkMfgEcmo9V2YpZ6tso53nTzVvWXJAJ3cZjsdPSu4vBHMA5/MmT7QC YhGqkV7/EjTm84USINO7219lEzi1W2A0EvAMOpp0Vyui7wm5wJpJO1wM5kh2g3Bo R6QZSuHBM/qC3A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=GkSpyVk3xEIb62MAv2CZYEpBOtVmj 7EIU28X5QIUI1U=; b=GnR7PKBB+pE5ISuRclQEd8ugWg290Z2g5g4z9vTNHp8Gc 5/1SxKH22ZrXOIe7rZT7xci1UvWgPOK42U+jd52WmYuts+KXxlLlnYrdtEvt9xwB ijx8QHq7F/VH6rZkaZPL3+6PPOJI3joOM2y/8cpZc0W1bNatZdNmrhr+JFu6SpAO rv2fZZAzQANr8kD983FDPgCPLngojK3AznC3pTEBfZ2D8L9Y53FBFj4OyJ+KOJAJ VHeE0UM6/LpyUUMQKC2FXpg9yE6JwZlwbOLGUreNKuItr3B/OhVPwiFcrCIaGHPY eRj6h7rrCDbF/4rwEJtVvh6b2f0P8L/To5XorS32g== X-ME-Sender: Received: from [10.24.6.172] (unknown [128.107.241.167]) by mail.messagingengine.com (Postfix) with ESMTPA id 3A7A87F8DD; Thu, 9 Nov 2017 22:38:20 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4F84EFD6-8D53-4BE0-98A3-F57DF9558297" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Fri, 10 Nov 2017 11:38:18 +0800 Cc: iasa20@ietf.org Message-Id: References: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> <6B399B19-037A-4F59-A35C-73FEF074F7C1@gmail.com> <20171108214708.3twjdffmjhknqarz@mx4.yitter.info> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 03:38:25 -0000 --Apple-Mail=_4F84EFD6-8D53-4BE0-98A3-F57DF9558297 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Brian, > On Nov 9, 2017, at 5:59 AM, Brian E Carpenter = wrote: >=20 > On 09/11/2017 10:47, Andrew Sullivan wrote: >> On Wed, Nov 08, 2017 at 01:27:49PM -0800, Bob Hinden wrote: >>=20 >>> I think our fund raising difficulties have little to do with how we = are organized. >>=20 >> Well, this is just an anecdote, but it matters in at least _some_ >> cases. I personally made appeals to people whose response was, "Why >> should I give more money to ISOC?" Our answer today has to be, = "Trust >> us, it's a dedicated fund," because we don't have a different >> governance organization controlling the money. >>=20 >> Now, this might have been because of the people I was talking to, and >> their peculiar focus at the time on governance issues. But it >> certainly isn't an objection to which we have an obvious retort. >=20 > As in "Which word in 'dedicated' don't you understand?" ? >=20 > I'm not denying that some potential patrons might suffer from this = confusion > for a few minutes. But since it's only a matter of some clear wording > about separate accounts and dedicated funds, I truly find it hard > to put much weight on this argument. If we don't have that clear = wording > already clearly displayed, that's a problem that should be soluble > within a few days of deciding to solve it. I think if you look back at the minutes from the BoF at IETF 98 [1], you = get quite a different picture. There we had three of the four Global = Host companies explaining that separate entities receiving the = sponsorship money would make it easier to be an IETF sponsor. I will say = that I have personally observed confusion about this within Cisco that = wouldn=E2=80=99t exist if the IETF and ISOC were distinct legal = entities. Words can=E2=80=99t fix this, because at the end of the day = the name on the check has to be tied to a tax ID, and you can=E2=80=99t = get your own tax ID if you=E2=80=99re not a legal entity. This is a = different argument from the one about governance of the funds and = trusting that they will be spent how they=E2=80=99re supposed to be, but = since I=E2=80=99ve seen the confusion first hand on more than one = occasion, I thought I would mention it. Earlier this year the IAOC stood up a committee to help strategize about = sponsorship. The committee has been slowly grinding gears on a few = different aspects of IETF sponsorship, so no results to report yet. But = one of the very first issues we discussed was reducing the barriers to = becoming a sponsor, and the perception even among existing sponsors that = giving money to the IETF is difficult. Alissa [1] https://datatracker.ietf.org/meeting/98/materials/minutes-98-iasa20/ = >=20 > Brian >=20 > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 --Apple-Mail=_4F84EFD6-8D53-4BE0-98A3-F57DF9558297 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Brian,

On Nov 9, 2017, at 5:59 AM, = Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

On = 09/11/2017 10:47, Andrew Sullivan wrote:
On Wed, Nov 08, 2017 at 01:27:49PM -0800, Bob = Hinden wrote:

I think our fund raising difficulties have little to do with = how we are organized.

Well, = this is just an anecdote, but it matters in at least _some_
cases.  I personally made appeals to people whose = response was, "Why
should I give more money to ISOC?" =  Our answer today has to be, "Trust
us, it's a = dedicated fund," because we don't have a different
governance organization controlling the money.

Now, this might have been because of the = people I was talking to, and
their peculiar focus at the = time on governance issues.  But it
certainly isn't an = objection to which we have an obvious retort.

As in "Which word in 'dedicated' = don't you understand?" ?

I'm not denying = that some potential patrons might suffer from this confusion
for a few minutes. But since it's only a matter of some clear = wording
about separate accounts and dedicated funds, I = truly find it hard
to put much weight on this argument. If = we don't have that clear wording
already clearly = displayed, that's a problem that should be soluble
within = a few days of deciding to solve it.

I = think if you look back at the minutes from the BoF at IETF 98 [1], you = get quite a different picture. There we had three of the four Global = Host companies explaining that separate entities receiving the = sponsorship money would make it easier to be an IETF sponsor. I will say = that I have personally observed confusion about this within Cisco that = wouldn=E2=80=99t exist if the IETF and ISOC were distinct legal = entities. Words can=E2=80=99t fix this, because at the end of the day = the name on the check has to be tied to a tax ID, and you can=E2=80=99t = get your own tax ID if you=E2=80=99re not a legal entity. This is a = different argument from the one about governance of the funds and = trusting that they will be spent how they=E2=80=99re supposed to be, but = since I=E2=80=99ve seen the confusion first hand on more than one = occasion, I thought I would mention it.

Earlier this year the IAOC stood up a committee to = help strategize about sponsorship. The committee has been slowly = grinding gears on a few different aspects of IETF sponsorship, so no = results to report yet. But one of the very first issues we discussed was = reducing the barriers to becoming a sponsor, and the perception even = among existing sponsors that giving money to the IETF is = difficult.

Alissa



  Brian

_______________________________________________
iasa20 mailing list
iasa20@ietf.org
https://www.ietf.org/mailman/listinfo/iasa20

= --Apple-Mail=_4F84EFD6-8D53-4BE0-98A3-F57DF9558297-- From nobody Thu Nov 9 19:53:58 2017 Return-Path: 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 A237A124205 for ; Thu, 9 Nov 2017 19:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YPIBfYEX-9xy for ; Thu, 9 Nov 2017 19:53:54 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44EFD120713 for ; Thu, 9 Nov 2017 19:53:54 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id 207so3663027pgc.12 for ; Thu, 09 Nov 2017 19:53:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xaK4QtXQ+9YsdWluhyzYZonNsu+0VanlHGBKqOeNS/Y=; b=WbeOZbGkQKpBNx/vP6PuBHgi1ZNAdiB/are4btIySDwP7XKeFu3lWK4F1rJKCp8MXd 92ELJoG3H/rHWj7j6QNCs05Hlpzg3MHnyyUsxaWS9m0oCLP1R57/DVkmVT9xfv6qrF3d zEMQNUfkSow0BcuOjocLMCIdGjjccqDhX8n3zNIJFgzLBbganaTZYEWK9QJfLVOjwt8W +rBx506/4EwIYa6aCKYW0Xphpmueko7Y48sw6PEgq2eDGcWlKcnpXpc7JWErpidHYI2N Xt3LN1/l2B1YmKy0uC7Ygx0OEXFNvguvvZJ3GPEuZbsMGBrC0NifZe7OtXycR9kE7z04 ZFKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=xaK4QtXQ+9YsdWluhyzYZonNsu+0VanlHGBKqOeNS/Y=; b=JK4Dsxu6wQo0+KPEWQMV9+l5Y4rbokNK7JWJNqZg1SnFonFAoc/mTwCEJwAPJzl02U 1Kmim2k2eYwneNxcG7GZK4UGemunfyV9HLYi9aChcewpyZnPQIFxviIl3TwvgYQf4dZv 2a3skA63X+aNhfTLDgJer/TAlNogk45UYUCQZJApWfx4XsVtZgPA4rKeFOX4NDlSAvsS HKQxBjiRolxpcGKVhmwyil0+KBf01fpXiVGizlJp7mpn/baEroWV7i6gZLna9Ck9JWne 93uGKxmzcZMlLxV/QD+20ZdJ+beaQQZeny2WtABD6slJ989tgEp1CGHR1r/wn5AbHJ14 nSBA== X-Gm-Message-State: AJaThX447i927h7P91sRqNC5/z8Q3nQIMyKs/OgXwfkAF5OaDe7IbLf5 7eo1vw+JAtvhIpKVADCJo4DTug== X-Google-Smtp-Source: ABhQp+SjbEjCaTwK2k0hRk8kPneMZgc9Un9nuQlWpIPa4PKx4yf2U/vT38B/wKFfSJnMu266HcMdvg== X-Received: by 10.101.80.205 with SMTP id s13mr2711596pgp.68.1510286033398; Thu, 09 Nov 2017 19:53:53 -0800 (PST) Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z71sm3018282pfi.172.2017.11.09.19.53.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 19:53:52 -0800 (PST) To: Alissa Cooper Cc: iasa20@ietf.org References: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> <6B399B19-037A-4F59-A35C-73FEF074F7C1@gmail.com> <20171108214708.3twjdffmjhknqarz@mx4.yitter.info> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5e20b0d0-ef60-aa34-63d3-672a5a509ee9@gmail.com> Date: Fri, 10 Nov 2017 16:53:57 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 03:53:57 -0000 On 10/11/2017 16:38, Alissa Cooper wrote: > Hi Brian, >=20 >> On Nov 9, 2017, at 5:59 AM, Brian E Carpenter wrote: >> >> On 09/11/2017 10:47, Andrew Sullivan wrote: >>> On Wed, Nov 08, 2017 at 01:27:49PM -0800, Bob Hinden wrote: >>> >>>> I think our fund raising difficulties have little to do with how we = are organized. >>> >>> Well, this is just an anecdote, but it matters in at least _some_ >>> cases. I personally made appeals to people whose response was, "Why >>> should I give more money to ISOC?" Our answer today has to be, "Trus= t >>> us, it's a dedicated fund," because we don't have a different >>> governance organization controlling the money. >>> >>> Now, this might have been because of the people I was talking to, and= >>> their peculiar focus at the time on governance issues. But it >>> certainly isn't an objection to which we have an obvious retort. >> >> As in "Which word in 'dedicated' don't you understand?" ? >> >> I'm not denying that some potential patrons might suffer from this con= fusion >> for a few minutes. But since it's only a matter of some clear wording >> about separate accounts and dedicated funds, I truly find it hard >> to put much weight on this argument. If we don't have that clear wordi= ng >> already clearly displayed, that's a problem that should be soluble >> within a few days of deciding to solve it. >=20 > I think if you look back at the minutes from the BoF at IETF 98 [1], yo= u get quite a different picture. There we had three of the four Global Ho= st companies explaining that separate entities receiving the sponsorship = money would make it easier to be an IETF sponsor. I will say that I have = personally observed confusion about this within Cisco that wouldn=E2=80=99= t exist if the IETF and ISOC were distinct legal entities. Words can=E2=80= =99t fix this, because at the end of the day the name on the check has to= be tied to a tax ID, and you can=E2=80=99t get your own tax ID if you=E2= =80=99re not a legal entity. This is a different argument from the one ab= out governance of the funds and trusting that they will be spent how they= =E2=80=99re supposed to be, but since I=E2=80=99ve seen the confusion fir= st hand on more than one occasion, I thought I would mention it. >=20 > Earlier this year the IAOC stood up a committee to help strategize abou= t sponsorship. The committee has been slowly grinding gears on a few diff= erent aspects of IETF sponsorship, so no results to report yet. But one o= f the very first issues we discussed was reducing the barriers to becomin= g a sponsor, and the perception even among existing sponsors that giving = money to the IETF is difficult. Yes. That was true even 10 years ago. What I found was that the tricky bi= t was justifying the *marketing* value to the sponsor. In most companies, that sort of money comes from Marketing, not from R&D. In some ways ISOC was an easier sell from that viewpoint than the IETF; policy and governan= ce are more saleable than standards. Explaining that ISOC handl= ed the money so that geeks didn't need to always seemed easy enough at that = time. To be clear, I fully support the need for a professional fund-raiser, in any of the models. Brian >=20 > Alissa >=20 > [1] https://datatracker.ietf.org/meeting/98/materials/minutes-98-iasa20= / >> >> Brian >> >> _______________________________________________ >> iasa20 mailing list >> iasa20@ietf.org >> https://www.ietf.org/mailman/listinfo/iasa20 >=20 >=20 From nobody Thu Nov 9 20:02:29 2017 Return-Path: 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 CC237129462 for ; Thu, 9 Nov 2017 20:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=HsvSXUuc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KyrQaioO 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 a0AadYvvqChr for ; Thu, 9 Nov 2017 20:02:25 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DEDB12943A for ; Thu, 9 Nov 2017 20:02:25 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 9378720CCD; Thu, 9 Nov 2017 23:02:24 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 09 Nov 2017 23:02:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=q2u253Yugu8EY/WezP47JjWv54ckn BNJz3ysf97KI0k=; b=HsvSXUuctbKrrW4WmimLytc06cQ3rJg7VLsRjUcNDv/mM Zot8UbS80nDE5zQdbrnYD+p9X2dtxT8WfD8se5cv1cjjfWw2m0JpKp17BDyWzA6y m0Rklp7t9jJfBy6P4V0Kd/9HVz/c5uG6kZzOJTUujVJFCpdzv6jB19XgxlTSZQV5 1eP21BfCpBhrp46n3c3QJ/wKzESZmt2PD5FF6vAQjQdPCBEN8jGgI39SEM5Hmlwq Mugsxa1LWEuVEySE86ZmMdEbjUIkQmkf4bL38PuhO+vHQPVm+hcnxiBNexQGMqGZ Y5UzP647GQdpypMH7R96DNJMmbbIHvUcmM+x2lE8A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=q2u253 Yugu8EY/WezP47JjWv54cknBNJz3ysf97KI0k=; b=KyrQaioOjlCk9pcTzaVUlr ro5D/kUqVSmj/qIHU+8hoOJOJ5dNy/oroG48l3fsy5rumvSbrTYvMjubVsulXy5p 5XeGgsIJQhc6gtFju2MJkxrfjRMxx5+9Lw7rrH4KChlnbQ47XVrGnnDfYxNmgibt w5G58FIEnFGeiecPfnrQL5NHrvU5MqU/wTt4xkjl0hPilroZ9zLd4o+eAyb+BFNh jiB2zlV7VcDVwbTbAFeyJM5PRBo9bQ291C/2UBPXJe+f4RUcMNxg4AqVK3NS71z9 ZWapPZHLyixH/nqj4v74aPfbKA3BSqZybhshiAWSq+eUW0KXjnuD+tstXzDE8KXQ == X-ME-Sender: Received: from [10.24.6.172] (unknown [128.107.241.167]) by mail.messagingengine.com (Postfix) with ESMTPA id 9165E7FAF7; Thu, 9 Nov 2017 23:02:23 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <11f08b34-81b3-48b8-30e3-5484376abc73@gmail.com> Date: Fri, 10 Nov 2017 12:02:20 +0800 Cc: iasa20@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3EF735B3-981F-468A-9F90-A0403CF16A67@cooperw.in> References: <11f08b34-81b3-48b8-30e3-5484376abc73@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Iasa20] The three options X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 04:02:28 -0000 Hi Brian, > On Nov 8, 2017, at 10:09 AM, Brian E Carpenter = wrote: >=20 > I have to say that the new draft hasn't changed my opinion about > what we should do. >=20 > 1) I think that the overheads, the bureaucracy and the risks of = creating > a new independent legal entity are out of all proportion to the gains. The size of the bureaucracy has been mentioned a few times as folks = consider the design team=E2=80=99s work, so I wanted to share some = observations on that based on recent experience. It seems like some folks have the impression that administering the IETF = in the way we do it now does not involve much bureaucracy. But what = I=E2=80=99ve found is that rather than escaping bureaucracy by not = legally existing and by relying on ISOC to employ the people we need = employed, what we=E2=80=99re subject to in practice is a large = bureaucracy over which we have very little control =E2=80=94 ISOC's. = ISOC=E2=80=99s bureaucracy is built for 100 employees and a $45 million = budget. Because we rely on ISOC employees and contractors, we don=E2=80=99= t have much choice as far as navigating its bureaucracy, but we also = don=E2=80=99t have much hand in shaping it (other than our appointment = of trustees, whose influence over this is somewhat attenuated, I = assume). So I read the assessment of the subsidiary and independent = options as providing an opportunity for more control over the = bureaucratic aspects and for scoping them down to the size of our = operation, as compared to what we have now. =20 Alissa > And it would not reduce our financial dependence on ISOC by one kopek. > On the contrary, it would in the long run reduce ISOC's motivation > to support the IETF. (One of the several mechanisms behind that is > that with an extra Board to staff, we'd have fewer IETF folk willing > to serve on the ISOC Board, so over time they would hear less from > us and therefore see less reason to feed us.) >=20 > Also, after ten years or so, the IETF would be complaining at the > lack of transparency in the new organization, its failure to listen, > and its stupid choice of venue for IETF 135. >=20 > 2) I could live with an ISOC subsidiary. But it's only a fancy way > of separating the accounts, so I don't really see what we gain. What > we pay is a bit more bureaucracy. >=20 > 3) So I think that IASA++, *done properly*, is the least costly > and least risky option. I hope my comments on the draft indicate > what I mean by 'properly'. >=20 > Now I'll go and read other opinions, which I've carefully avoided > so far. >=20 > Regards > Brian >=20 > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 From nobody Fri Nov 10 07:54:34 2017 Return-Path: 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 A0554126CD8 for ; Fri, 10 Nov 2017 07:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 5DYcg_4ZhOFU for ; Fri, 10 Nov 2017 07:54:30 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 6D74A126C3D for ; Fri, 10 Nov 2017 07:54:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id ABA382CFBA; Fri, 10 Nov 2017 17:54:28 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igM5-cFnXP3v; Fri, 10 Nov 2017 17:54:27 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 132362CE21; Fri, 10 Nov 2017 17:54:26 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Fri, 10 Nov 2017 23:54:24 +0800 Cc: Brian E Carpenter , iasa20@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> <6B399B19-037A-4F59-A35C-73FEF074F7C1@gmail.com> <20171108214708.3twjdffmjhknqarz@mx4.yitter.info> To: Alissa Cooper X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 15:54:33 -0000 > I think if you look back at the minutes from the BoF at IETF 98 [1], = you get quite a different picture. There we had three of the four Global = Host companies explaining that separate entities receiving the = sponsorship money would make it easier to be an IETF sponsor. I can also confirm this, and have witnessed the wish in other instances = as well. Also, over the years, many clarifying words have been provided, = but it isn=E2=80=99t quite as easily solved as that. At the end of the = day, my belief is that further organisational clarity would be = beneficial for our fundraising efforts. Certainly not the only or solely = sufficient tool as Andrew pointed out, but I think it should be one of = the tools.=20 Jari From nobody Fri Nov 10 08:03:06 2017 Return-Path: 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 0ED70126CE8 for ; Fri, 10 Nov 2017 08:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 biBU2Odvnbi3 for ; Fri, 10 Nov 2017 08:02:59 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3071B126C3D for ; Fri, 10 Nov 2017 08:02:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B868C2CFBA; Fri, 10 Nov 2017 18:02:57 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFmnauoN4XT2; Fri, 10 Nov 2017 18:02:57 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 6753E2CE21; Fri, 10 Nov 2017 18:02:56 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <3EF735B3-981F-468A-9F90-A0403CF16A67@cooperw.in> Date: Sat, 11 Nov 2017 00:02:54 +0800 Cc: iasa20@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <54251150-8CC8-4547-8F2C-DABDE32082D2@piuha.net> References: <11f08b34-81b3-48b8-30e3-5484376abc73@gmail.com> <3EF735B3-981F-468A-9F90-A0403CF16A67@cooperw.in> To: Alissa Cooper , Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] The three options X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 16:03:05 -0000 Brian=E2=80=99s preference noted. Thanks for your feedback! If I may characterise Alissa=E2=80=99s impressions with slightly = different words: Control and clarity over informality and lack of = structure. Whereas you Brian prefer both minimising unnecessary = structure and distance from an important funding partner. Jari From nobody Fri Nov 10 08:29:07 2017 Return-Path: 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 216E3126CD6 for ; Fri, 10 Nov 2017 08:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 TpFMavRij5gs for ; Fri, 10 Nov 2017 08:29:04 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 1981B1243F3 for ; Fri, 10 Nov 2017 08:29:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E272C2CFCF; Fri, 10 Nov 2017 18:29:02 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QwM-oMz3pWd; Fri, 10 Nov 2017 18:29:02 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 808762CE21; Fri, 10 Nov 2017 18:29:01 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <2de8f0bd-6009-1375-c60d-4921a77e4d18@gmail.com> Date: Sat, 11 Nov 2017 00:28:59 +0800 Cc: iasa20@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150826730924.11473.15624020870916138544@ietfa.amsl.com> <2de8f0bd-6009-1375-c60d-4921a77e4d18@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] I-D Action: draft-haberman-iasa20dt-recs-01.txt X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 16:29:07 -0000 Thanks for your in-depth input, Brian. Few points below: >=20 >> 3.1.4. Oversight >=20 > All the points in this section are valid, but I think an important > issue is still missing: it doesn't capture the conflict of interest > when overseers (members of the IAOC) are also volunteer workers > for the IASA. I believe that conflict is real and has caused > confusion and failures of oversight in the past. Ack, and agreed. >> 3.2.1. Volunteers > ... >> IETFAdminOrg must rely less on volunteers or be better assured of >> engagement of willing and capable volunteers. >=20 > I think this needs to be more explicit, e.g. >=20 > IETFAdminOrg must rely less on volunteers or be better assured of > engagement and formal commitments of willing and capable volunteers. >=20 > I believe somebody mentioned a while back that other professional > bodies get their volunteers to sign a formal agreement. That may not > be IETF-style but there's nothing worse than a vanishing volunteer=E2=80= =A6 =E2=80=A6 except perhaps a volunteer that vanishes when you show the = agreement :-) Anyway, more seriously, do you have pointers to other organisations that = do this? Sorry, I don=E2=80=99t recall the previous discussion. >=20 >> 3.3. Lack of Transparency > ... >> Work to increase transparency has made progress, but we must = continue >> to address and improve this. At the same time, a balance must be >> struck to reach the right level of transparency, so that certain >> aspects of contracts, business terms, and negotiations can remain >> confidential, according to legal and business practice norms.=20 >=20 > That's good but I would add a final argument to the last sentence: >=20 > , and to preserve IASA's negotiating position. >=20 > There's nothing worse in negotiation than giving away your bottom > line in advance. Indeed. Good addition. >> 4. Goals > ... >> o Clarify Overall Roles and Responsibilities: Ensure that all = staff, >> contractor, and volunteer roles are clearly documented.=20 >=20 > Yes, but the list should *star*t with oversight roles. Yes. An omission. >> 5.1. Overall Structure >>=20 >> 5.1.1. IASA++ >=20 > All the points are valid but I think a few are missing: >=20 > o Precise definitions of terms and conditions for volunteers >=20 > o Separate IAOC and Trust memberships >=20 > o Improve NomCom criteria accordingly >=20 > (These points really apply to all three models, of course.) Ack, and noted. As a personal comment, I am eager to learn more about item 1, but = (hopefully healthily) somewhat sceptical. Tell me more! I do agree with = item 2. And I like item 3, but not sure that is going to improve our = pool when it is quite limited for administrative tasks at the moment. >> 5.5. Staff Structure > ... >> o Executive Director. The person in this role is in charge of the >> overall IASA effort, but can rely on other staff members below = as >> well as contractors. The Executive Director is accountable to = the >> Board. >=20 > Since this applies to all three models, it should say >=20 > The Executive Director is accountable to the > IAOC or Board. Yes. Thanks. >> Note: The Executive Director likely needs to be a full-time = employee, >> as is likely the case for the other Director-level positions. >=20 > I object pretty strongly to the notion that we need a full time = Director > of Communications. In fact I don't understand why it would be = designated > as a Directorship at all. A fulltime webmaster, perhaps. But we aren't > in the communications business, except as an adjunct to fund-raising. Noted.=20 (Information from the last couple of years is that we=E2=80=99ve used a = communications professional quite a lot, on varying communications tasks = that included helping with press discussions, blogs and videos, the = website design, etc. We could argue how critical this is, but it has = been much beyond fund-raising.) >> 6.1. Comparison to Goals > ... >> In IASA++, leaving the responsibility for sponsorship = fundraising >> up to ISOC, as BCP 101 does, means we will always be constrained >> by however ISOC is willing to staff and support IETF-specific >> fundraising.=20 >=20 > But as I understand the IASA++ proposal, that is not proposed, except > that the Director of Fundraising would be an ISOC employee. So this > is an unfair characterisation of the IASA++ model. Ack. So the point is that under IASA++, if we together with ISOC implement = the new directors (even if they are ISOC employees) then from that = perspective there is no change. Agreed. There may be of course be some = other differences wrt funding and the options, but that we can discuss = separately... > ...> In the IASA++ option, there is limited improvement on = clarity of >> the financial arrangements. >=20 > Again, unfair. Whether the financial arrangements are clear is 100% > dependent on the clarity of accounting. Once we correct the error > of ISOC staff working for the IETF without their time being paid > by the IETF budget, this problem goes away in all three models. Comment acknowledged. (Here we might find some disagreement though.) > ... >> However, in IASA++, some of lack of clarity may remain, as lack = of >> clarity inherent in two organizations controlling resources may >> remain.=20 >=20 > Again, unfair. If we do it right - charge staff time to the IETF = budget - > there will be no issue. We also need to clarify volunteer commitments, > of course, but that goes for all three models too. Ack, and see above. Although here your earlier comment that IASA++ would = also need an agreement re: funding with ISOC may help things. > ... >> o Improve Transparency: > ... >> ... The IAOC and committees have been operating with >> their current structure, and, in some cases, current volunteers/ >> personnel, for a long time. It will be harder for them to = change >> than to make staff-driven changes in an org with new staff. >=20 > There's some truth in that, but with a new broom (a new Director) > in place, clarification of volunteer roles, and some very clear > direction from the community to the IAOC, I don't see it as > insurmountable. Ack.=20 (Nothing is unsurmountable; we have a working system but there are = people wishing to improve how it operates, and sometimes, at least in my = experience, some pain in the current system.) Jari From nobody Fri Nov 10 09:08:24 2017 Return-Path: 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 31B5A12EC31 for ; Fri, 10 Nov 2017 09:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 RkPUgFzzo_fY for ; Fri, 10 Nov 2017 09:08:21 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id E450312EC43 for ; Fri, 10 Nov 2017 09:08:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9B9E82CFBA; Fri, 10 Nov 2017 19:08:06 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBOwTsN44t1D; Fri, 10 Nov 2017 19:08:06 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 5C0E82CE21; Fri, 10 Nov 2017 19:08:05 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <8B56C5FB-2402-47AC-893A-891ACF53814B@cooperw.in> Date: Sat, 11 Nov 2017 01:08:03 +0800 Cc: iasa20@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7980195A-4681-4594-8661-4CF76499625C@piuha.net> References: <8B56C5FB-2402-47AC-893A-891ACF53814B@cooperw.in> To: Alissa Cooper , Bob Hinden X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Comments on X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 17:08:23 -0000 Thanks for your input, Bob! (FWIW, I personally do agree with Alissa=E2=80=99s point of view that = the leadership entities even outside IAOC do take cost into account. But = I would characterise our current system as not having the processes = around this particularly formalised, and there=E2=80=99s usually quite a = bit of back-and-forth and cross-posting emails when something is = discussed. This might or might not be a problem, depending on your point = of view.) Jari From nobody Fri Nov 10 09:32:59 2017 Return-Path: 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 7EB2B12EC4B for ; Fri, 10 Nov 2017 09:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 7BfE2UUQFHx7 for ; Fri, 10 Nov 2017 09:32:56 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB91312EC68 for ; Fri, 10 Nov 2017 09:32:54 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4F4BC20008 for ; Fri, 10 Nov 2017 12:34:18 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 67C6C80661 for ; Fri, 10 Nov 2017 12:32:53 -0500 (EST) From: Michael Richardson To: iasa20@ietf.org In-Reply-To: X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Iasa20] The three options X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 17:32:57 -0000 --=-=-= Content-Type: text/plain Alissa Cooper wrote: > employees and a $45 million budget. Because we rely on ISOC employees > and contractors, we don't have much choice as far as navigating its > bureaucracy, but we also don't have much hand in shaping it (other than > our appointment of trustees, whose influence over this is somewhat Note that I don't think it has to be this way. I think that ISOC could treat us more as an operating agency without us actually having to have a seperate legal entity. The recent move (which many in the community may not have absorbed) towards having AMSL provide the book-keeping and accounting support services rather than ISOC seems like a good move. I believe that this involved opening a new bank account, which I was surprised did not already exist. A seperate incorporation is not really that expensive or need have that much overhead; AMSL is already providing us with 90% of what we would need to do. So what are the political/social downsides of not being legally associated with ISOC? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloF4sUACgkQgItw+93Q 3WVv2QgAq5PL2qKHr1WQo7Tq2O+hR2thiiX0/tYGrdl4TLGLMHTNML7x/MEht15H D9NKa50GeqstO8Xp3gfLmDQkQ5GxqIWy2EfRFBk9f41KwOoIfVzID3TjMAPaUhjx l8iwFkWrURhpFElipIWN04gPZs0xcL+MiamXpD/XPUaxEGux4lpjKICCGCVxOVOM zoukc4YRGn9hvK1FR9/+D4Z18Tzf2ufdIJ/h47A1+lv8nVNQ88h4OPfyZ3GTe5YP csI3NLhJOUx6KGYgO6uv/D+aL18/Z8d3J7g3fiMJ+eLbayclXJsB74thV4QcOEqj wXhOVqgYEPpJFp9Ri71iwFAChIdJOQ== =nXLx -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 10 11:01:54 2017 Return-Path: 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 A32B41293E0 for ; Fri, 10 Nov 2017 11:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 ghDpl46lGJZE for ; Fri, 10 Nov 2017 11:01:50 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572BF1293E9 for ; Fri, 10 Nov 2017 11:01:50 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id n74so6835717wmi.1 for ; Fri, 10 Nov 2017 11:01:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e4AcZOPmJgUCSRyg6FOMUWtFwGFb0Uu6+09zGmZv/bI=; b=aAurOd9pQmkQQbqntPlEndUoGMuajQ/wAYkC2fEfUSIXu1tw8Fb6ZEkpb9fOkRDxbD 0izucCNcbzCETqR2qtd6S3KbB6MHvz086Ofr3C48fyMxTD2cyix47iZ9z8nhnAZUlk5P TmuzwAIyPavTyY4dP8LZ+HPfCfchReIwcO8rKvZqfPo3rshIdu6xxepaBG2mvc9muG4m f9pLC4GQT8lghozLHb1QySEj2IBQb/0Sk6XJhhiEmUFQpy9Ksh7uw9QE4oMlvopdqzCJ 3rVDwcztDuAx1ZzDHKJeyAfNqdbgGE7vYmMUCXPd+7Da71sSo7MIp4Pn0Ve5VMOfXoDG SGAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e4AcZOPmJgUCSRyg6FOMUWtFwGFb0Uu6+09zGmZv/bI=; b=uL5j/5oZM06KCZwexgneuDM6Y96D35oUESKeaseN5+UxKAw4wkjS3MN++koCTazsOA I+wgB3wuvi+OSuKr0Ayp9goaocf3RswmNVTSBQZ5TitemU/odF0RcWHQHdKLne9pfO29 ulu0qpzwVh1BVaqvgTriTz4elQ9YbrLPjuX3/L+Kebjenvbk6Zu9I7ftf+3D+wXed60F LBqb4Dj9RN+6O0jUDM8Yc2qmTOcr01uemt0C6yV07LEaPtSGXyH9BYVL+LzK9Sx1eiiz SYYYi0DQkm5gYrKVP3s3TUvgRUQg0Adw57fi8XIY1f6iZrNAt57fVpBwzY+/0eBcHnaF ApXg== X-Gm-Message-State: AJaThX5avKiX7IyGQcQfaT9lMyfNROfOwTY0ifwX8LugYRN1i4klqAio Z77RBwYtLGPZ3AaN1tm9KfxZgLiqLJ/uFnSQG1xnNg== X-Google-Smtp-Source: AGs4zMYNPOdMPNHkhp8CIEEbPDBnGFPAK1D39kA+IKxGq6OtGbzk0yURdirIznhFy4mmXa7CCIzulkkM8QUHQ25TJHM= X-Received: by 10.28.21.10 with SMTP id 10mr946375wmv.41.1510340508521; Fri, 10 Nov 2017 11:01:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Fri, 10 Nov 2017 11:01:47 -0800 (PST) In-Reply-To: <5e20b0d0-ef60-aa34-63d3-672a5a509ee9@gmail.com> References: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> <6B399B19-037A-4F59-A35C-73FEF074F7C1@gmail.com> <20171108214708.3twjdffmjhknqarz@mx4.yitter.info> <5e20b0d0-ef60-aa34-63d3-672a5a509ee9@gmail.com> From: Richard Barnes Date: Fri, 10 Nov 2017 14:01:47 -0500 Message-ID: To: Brian E Carpenter Cc: Alissa Cooper , iasa20@ietf.org Content-Type: multipart/alternative; boundary="001a1145a93280364f055da58d1f" Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 19:01:53 -0000 --001a1145a93280364f055da58d1f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 9, 2017 at 10:53 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 10/11/2017 16:38, Alissa Cooper wrote: > > Hi Brian, > > > >> On Nov 9, 2017, at 5:59 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> > >> On 09/11/2017 10:47, Andrew Sullivan wrote: > >>> On Wed, Nov 08, 2017 at 01:27:49PM -0800, Bob Hinden wrote: > >>> > >>>> I think our fund raising difficulties have little to do with how we > are organized. > >>> > >>> Well, this is just an anecdote, but it matters in at least _some_ > >>> cases. I personally made appeals to people whose response was, "Why > >>> should I give more money to ISOC?" Our answer today has to be, "Trus= t > >>> us, it's a dedicated fund," because we don't have a different > >>> governance organization controlling the money. > >>> > >>> Now, this might have been because of the people I was talking to, and > >>> their peculiar focus at the time on governance issues. But it > >>> certainly isn't an objection to which we have an obvious retort. > >> > >> As in "Which word in 'dedicated' don't you understand?" ? > >> > >> I'm not denying that some potential patrons might suffer from this > confusion > >> for a few minutes. But since it's only a matter of some clear wording > >> about separate accounts and dedicated funds, I truly find it hard > >> to put much weight on this argument. If we don't have that clear wordi= ng > >> already clearly displayed, that's a problem that should be soluble > >> within a few days of deciding to solve it. > > > > I think if you look back at the minutes from the BoF at IETF 98 [1], yo= u > get quite a different picture. There we had three of the four Global Host > companies explaining that separate entities receiving the sponsorship mon= ey > would make it easier to be an IETF sponsor. I will say that I have > personally observed confusion about this within Cisco that wouldn=E2=80= =99t exist > if the IETF and ISOC were distinct legal entities. Words can=E2=80=99t fi= x this, > because at the end of the day the name on the check has to be tied to a t= ax > ID, and you can=E2=80=99t get your own tax ID if you=E2=80=99re not a leg= al entity. This is > a different argument from the one about governance of the funds and > trusting that they will be spent how they=E2=80=99re supposed to be, but = since I=E2=80=99ve > seen the confusion first hand on more than one occasion, I thought I woul= d > mention it. > > > > Earlier this year the IAOC stood up a committee to help strategize abou= t > sponsorship. The committee has been slowly grinding gears on a few > different aspects of IETF sponsorship, so no results to report yet. But o= ne > of the very first issues we discussed was reducing the barriers to becomi= ng > a sponsor, and the perception even among existing sponsors that giving > money to the IETF is difficult. > > Yes. That was true even 10 years ago. What I found was that the tricky bi= t > was justifying the *marketing* value to the sponsor. In most companies, > that sort of money comes from Marketing, not from R&D. In some ways ISOC > was an easier sell from that viewpoint than the IETF; policy and governan= ce > are more saleable than standards. Explaining that ISOC handl= ed > the money so that geeks didn't need to always seemed easy enough at that > time. > This does not match my experience. The companies that are seriously investing in IETF understand the strategic value that the Internet and the IETF have to their companies. The challenges are exactly as Alissa says: These companies are judging the IETF as they would any other investment, and in particular, they want to understand how the resources they contribute are being used. If they want to donate to the IETF, writing a check to ISOC with some loose promise that "It will arrive at the IETF eventually" does not provide the assurance these organizations are looking for. --Richard > > To be clear, I fully support the need for a professional fund-raiser, in > any of the models. > > Brian > > > > > Alissa > > > > [1] https://datatracker.ietf.org/meeting/98/materials/minutes-98-iasa20= / > > >> > >> Brian > >> > >> _______________________________________________ > >> iasa20 mailing list > >> iasa20@ietf.org > >> https://www.ietf.org/mailman/listinfo/iasa20 > > > > > > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 > --001a1145a93280364f055da58d1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Nov 9, 2017 at 10:53 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
On 10/11/2017 16:38, Alissa Cooper wrote:
> Hi Brian,
>
>> On Nov 9, 2017, at 5:59 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: >>
>> On 09/11/2017 10:47, Andrew Sullivan wrote:
>>> On Wed, Nov 08, 2017 at 01:27:49PM -0800, Bob Hinden wrote: >>>
>>>> I think our fund raising difficulties have little to do wi= th how we are organized.
>>>
>>> Well, this is just an anecdote, but it matters in at least _so= me_
>>> cases.=C2=A0 I personally made appeals to people whose respons= e was, "Why
>>> should I give more money to ISOC?"=C2=A0 Our answer today= has to be, "Trust
>>> us, it's a dedicated fund," because we don't have= a different
>>> governance organization controlling the money.
>>>
>>> Now, this might have been because of the people I was talking = to, and
>>> their peculiar focus at the time on governance issues.=C2=A0 B= ut it
>>> certainly isn't an objection to which we have an obvious r= etort.
>>
>> As in "Which word in 'dedicated' don't you unders= tand?" ?
>>
>> I'm not denying that some potential patrons might suffer from = this confusion
>> for a few minutes. But since it's only a matter of some clear = wording
>> about separate accounts and dedicated funds, I truly find it hard<= br> >> to put much weight on this argument. If we don't have that cle= ar wording
>> already clearly displayed, that's a problem that should be sol= uble
>> within a few days of deciding to solve it.
>
> I think if you look back at the minutes from the BoF at IETF 98 [1], y= ou get quite a different picture. There we had three of the four Global Hos= t companies explaining that separate entities receiving the sponsorship mon= ey would make it easier to be an IETF sponsor. I will say that I have perso= nally observed confusion about this within Cisco that wouldn=E2=80=99t exis= t if the IETF and ISOC were distinct legal entities. Words can=E2=80=99t fi= x this, because at the end of the day the name on the check has to be tied = to a tax ID, and you can=E2=80=99t get your own tax ID if you=E2=80=99re no= t a legal entity. This is a different argument from the one about governanc= e of the funds and trusting that they will be spent how they=E2=80=99re sup= posed to be, but since I=E2=80=99ve seen the confusion first hand on more t= han one occasion, I thought I would mention it.
>
> Earlier this year the IAOC stood up a committee to help strategize abo= ut sponsorship. The committee has been slowly grinding gears on a few diffe= rent aspects of IETF sponsorship, so no results to report yet. But one of t= he very first issues we discussed was reducing the barriers to becoming a s= ponsor, and the perception even among existing sponsors that giving money t= o the IETF is difficult.

Yes. That was true even 10 years ago. What I found was that the tric= ky bit
was justifying the *marketing* value to the sponsor. In most companies,
that sort of money comes from Marketing, not from R&D. In some ways ISO= C
was an easier sell from that viewpoint than the IETF; policy and governance=
are more saleable than <yawn>standards</yawn>. Explaining that = ISOC handled
the money so that geeks didn't need to always seemed easy enough at tha= t time.

This does not match my experien= ce.=C2=A0 The companies that are seriously investing in IETF understand the= strategic value that the Internet and the IETF have to their companies.=C2= =A0 The challenges are exactly as Alissa says: These companies are judging = the IETF as they would any other investment, and in particular, they want t= o understand how the resources they contribute are being used.=C2=A0 If the= y want to donate to the IETF, writing a check to ISOC with some loose promi= se that "It will arrive at the IETF eventually" does not provide = the assurance these organizations are looking for.

--Richard

=C2=A0

To be clear, I fully support the need for a professional fund-raiser, in any of the models.

=C2=A0 =C2=A0 Brian

>
> Alissa
>
> [1] https://datatracker.iet= f.org/meeting/98/materials/minutes-98-iasa20/ <https://datatracker.ietf.org/meeting= /98/materials/minutes-98-iasa20/>
>>
>>=C2=A0 =C2=A0Brian
>>
>> _______________________________________________
>> iasa20 mailing list
>> iasa20@ietf.org
>> https://www.ietf.org/mailman/listinfo/iasa= 20
>
>

_______________________________________________
iasa20 mailing list
iasa20@ietf.org
https://www.ietf.org/mailman/listinfo/iasa20

--001a1145a93280364f055da58d1f-- From nobody Fri Nov 10 11:14:52 2017 Return-Path: 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 D739E1292F5 for ; Fri, 10 Nov 2017 11:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7G3qeK_bY20Y for ; Fri, 10 Nov 2017 11:14:50 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AFE7126C26 for ; Fri, 10 Nov 2017 11:14:50 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id g6so8072336pgn.6 for ; Fri, 10 Nov 2017 11:14:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Nlw0QmsEQfJR//MKhzCC++6bJLHejWjXb/8F2d7Umh0=; b=WTa6W1XTnRK4pvSxqUulyz0OiOb9myNqN5persGoerSpOAq+SVDAD5cM/iOR3ePkk5 1X7S/Jb3On+/Y3AacygdfPRhOABdHW1cK8+gNpm5ChvGgXA57owCpT8CTmPq4K1Qxp3s 1GIS8mYxRowmbPgo9gUC16jI2rpqGkb4xeHvhUUtT4iRFeoOQGjBGDNarF8RKVeXqgOy FMKcavB5yhjclMvYGGOmExEScPetpRyn69VhtaBo8YH+U4pSkvNe6SIchHKwPsGOE5Sn +GfcVC27vlX0P+3zv9cJB066R5kzBhWydrrqbUl2xiRqb2lQAsQtFVucJOlT9/s3HzOe PXBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Nlw0QmsEQfJR//MKhzCC++6bJLHejWjXb/8F2d7Umh0=; b=JqOWVUpLQ22wV3/RkQ5UMKBUKOCXoNk4JPHF7PXLxCIaREFBFKta1p4YQQLhdmv4gj 4W8wGPmjr5rtEHW0SMUdxERwWUJh9laDQSSiXDRfj29CB/M/cxkJ6myPvmTpqpvlEznV y389e73CdjTn8ei/qwsbfkes+WUjbhhdI3eGCgHWj7M78ob3ZrcrPJvUUiOhUJq1VgRB keB/upGWmLqOJhfz4go9h7fef/uSjEaoLPivPBY6KxA3l7Z1hBIIqGjA1FrQWPnE1k/x pZxJhXB8HaFk3ZcKCaAxsV5igrk+Cwv1NzkT6yPB6+ir5qUpTL+NFq9axEDnQoWZ0qGB CwPQ== X-Gm-Message-State: AJaThX6ik2tLvYisWMMRHVJeB0bGez41E4vCw3Hce5uaELVjT18uZSz/ 3GFKjFfnH3dHsqBSpRXERfvHJg== X-Google-Smtp-Source: AGs4zMawsbldtxOMYeGn2U/bei9Pl6h9zfry7aApusUXT/2V0xn0TyUujwcGlOwlue1/lOa1Q7Opuw== X-Received: by 10.101.77.208 with SMTP id q16mr1304728pgt.146.1510341289840; Fri, 10 Nov 2017 11:14:49 -0800 (PST) Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id j12sm21637177pfe.160.2017.11.10.11.14.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 11:14:48 -0800 (PST) To: Jari Arkko Cc: iasa20@ietf.org References: <150826730924.11473.15624020870916138544@ietfa.amsl.com> <2de8f0bd-6009-1375-c60d-4921a77e4d18@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 11 Nov 2017 08:14:55 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Iasa20] I-D Action: draft-haberman-iasa20dt-recs-01.txt X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 19:14:52 -0000 Thanks Jari. On one point: >=20 >>> 3.2.1. Volunteers >> ... >>> IETFAdminOrg must rely less on volunteers or be better assured of >>> engagement of willing and capable volunteers. >> >> I think this needs to be more explicit, e.g. >> >> IETFAdminOrg must rely less on volunteers or be better assured of >> engagement and formal commitments of willing and capable volunteers.= >> >> I believe somebody mentioned a while back that other professional >> bodies get their volunteers to sign a formal agreement. That may not >> be IETF-style but there's nothing worse than a vanishing volunteer=E2=80= =A6 >=20 > =E2=80=A6 except perhaps a volunteer that vanishes when you show the ag= reement :-) >=20 > Anyway, more seriously, do you have pointers to other organisations tha= t do this? Sorry, I don=E2=80=99t recall the previous discussion. >=20 I'm off to the airport shortly but I will look for this when I get the chance. Brian From nobody Fri Nov 10 11:25:11 2017 Return-Path: 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 F34AC1286C7 for ; Fri, 10 Nov 2017 11:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RPkoQFsZQ4eK for ; Fri, 10 Nov 2017 11:25:08 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098FD1204DA for ; Fri, 10 Nov 2017 11:25:08 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id 207so5290497pgc.12 for ; Fri, 10 Nov 2017 11:25:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=r7AhwQMP1R4lnRRRBaqPHrFYey7W9g2GpYkTcsqk39c=; b=CvvtcI7o7kk0Z7sxakCuWfbzoeeUt+6h8sZZa9TICU5EP3SVWQddzD4ujxPvgTiU6A XYwJ/4+FyLlniseKVu0GoTEWdlrv/7N9uT1gi5DrQJYxYz/y58AXPmU6Y7xVgSMlwSl0 PZpoKEjJDsCEDIl8XdCJsJe+jtdvEtAFcUAgZd71D9AH08Jwg6MrWDodq5PPuNV97P3C 1a7Nnz5L0r5EI38zCu0UuCmIFsGrcNQsJb5NBuYY6JG694KcPChFR83OCBKu/pew1BLi MfGlhn1PZIfTXbXviuC+9Pi2xTRigPYw/QZXKWewVv5KEDe7nqaYAx1v7fpJok6aiBvl WLEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=r7AhwQMP1R4lnRRRBaqPHrFYey7W9g2GpYkTcsqk39c=; b=dHnIjL24VuwNogPynT4EMcq1tIC2X6WckHX2VaeIaVmVxMSElnuoE4s5wv2U5BYEtI TEh94TXSontfGK7bwD0mvuAIr+PKjJNlZ5EsS/C8HTTMV/FMb0udrE48+6XH4odNcgv/ q7rEUs3L2E4wLYfFgXSSrZWTmNQuiDkR+fOW7MElAlPdyNwTgQViSw4Phai+whaC4Ox+ r4PptHcTdRviaQVBgADkx9NEA+Wen9By/XU/K0gb3pPFsQnMk/KO9/T0tmCYM5sZd7AL R00F2hJM5U36lyq3YA50sQxe92uETmD7cpGmRB9FCRciQm6ygPNOH1AP1d9OHXxKQArx JEOA== X-Gm-Message-State: AJaThX4L5dvqTP+ykQfK6zQzlsxzhMylx2QySGqyqARbeQyUPVO00wTl W3OK6jlVBu3XH1Ev8LY9aL4qTw== X-Google-Smtp-Source: AGs4zMazyuQGW7G1up1AIsQfLaReaCGcw2xui3JW8ClQN1v23VCO1auU6d1ilx72G2+R73FjQR8WkA== X-Received: by 10.99.165.25 with SMTP id n25mr1296970pgf.3.1510341907244; Fri, 10 Nov 2017 11:25:07 -0800 (PST) Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id h70sm19467165pfc.88.2017.11.10.11.25.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 11:25:06 -0800 (PST) To: Richard Barnes Cc: Alissa Cooper , iasa20@ietf.org References: <15AB0F9C-3DC9-4732-9EEC-04286417C5A5@isoc.org> <6B399B19-037A-4F59-A35C-73FEF074F7C1@gmail.com> <20171108214708.3twjdffmjhknqarz@mx4.yitter.info> <5e20b0d0-ef60-aa34-63d3-672a5a509ee9@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <11023e49-ab37-ff36-f7ca-98192582ed80@gmail.com> Date: Sat, 11 Nov 2017 08:25:13 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 19:25:10 -0000 On 11/11/2017 08:01, Richard Barnes wrote: > On Thu, Nov 9, 2017 at 10:53 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: >=20 >> On 10/11/2017 16:38, Alissa Cooper wrote: >>> Hi Brian, >>> >>>> On Nov 9, 2017, at 5:59 AM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >>>> >>>> On 09/11/2017 10:47, Andrew Sullivan wrote: >>>>> On Wed, Nov 08, 2017 at 01:27:49PM -0800, Bob Hinden wrote: >>>>> >>>>>> I think our fund raising difficulties have little to do with how w= e >> are organized. >>>>> >>>>> Well, this is just an anecdote, but it matters in at least _some_ >>>>> cases. I personally made appeals to people whose response was, "Wh= y >>>>> should I give more money to ISOC?" Our answer today has to be, "Tr= ust >>>>> us, it's a dedicated fund," because we don't have a different >>>>> governance organization controlling the money. >>>>> >>>>> Now, this might have been because of the people I was talking to, a= nd >>>>> their peculiar focus at the time on governance issues. But it >>>>> certainly isn't an objection to which we have an obvious retort. >>>> >>>> As in "Which word in 'dedicated' don't you understand?" ? >>>> >>>> I'm not denying that some potential patrons might suffer from this >> confusion >>>> for a few minutes. But since it's only a matter of some clear wordin= g >>>> about separate accounts and dedicated funds, I truly find it hard >>>> to put much weight on this argument. If we don't have that clear wor= ding >>>> already clearly displayed, that's a problem that should be soluble >>>> within a few days of deciding to solve it. >>> >>> I think if you look back at the minutes from the BoF at IETF 98 [1], = you >> get quite a different picture. There we had three of the four Global H= ost >> companies explaining that separate entities receiving the sponsorship = money >> would make it easier to be an IETF sponsor. I will say that I have >> personally observed confusion about this within Cisco that wouldn=E2=80= =99t exist >> if the IETF and ISOC were distinct legal entities. Words can=E2=80=99t= fix this, >> because at the end of the day the name on the check has to be tied to = a tax >> ID, and you can=E2=80=99t get your own tax ID if you=E2=80=99re not a = legal entity. This is >> a different argument from the one about governance of the funds and >> trusting that they will be spent how they=E2=80=99re supposed to be, b= ut since I=E2=80=99ve >> seen the confusion first hand on more than one occasion, I thought I w= ould >> mention it. >>> >>> Earlier this year the IAOC stood up a committee to help strategize ab= out >> sponsorship. The committee has been slowly grinding gears on a few >> different aspects of IETF sponsorship, so no results to report yet. Bu= t one >> of the very first issues we discussed was reducing the barriers to bec= oming >> a sponsor, and the perception even among existing sponsors that giving= >> money to the IETF is difficult. >> >> Yes. That was true even 10 years ago. What I found was that the tricky= bit >> was justifying the *marketing* value to the sponsor. In most companies= , >> that sort of money comes from Marketing, not from R&D. In some ways IS= OC >> was an easier sell from that viewpoint than the IETF; policy and gover= nance >> are more saleable than standards. Explaining that ISOC ha= ndled >> the money so that geeks didn't need to always seemed easy enough at th= at >> time. >> >=20 > This does not match my experience. The companies that are seriously > investing in IETF understand the strategic value that the Internet and = the > IETF have to their companies. =20 I'm glad that such companies exist, but if they value the IETF, the decision is surely not being driven by marketing people? > The challenges are exactly as Alissa says: > These companies are judging the IETF as they would any other investment= , > and in particular, they want to understand how the resources they > contribute are being used. If they want to donate to the IETF, writing= a > check to ISOC with some loose promise that "It will arrive at the IETF > eventually" does not provide the assurance these organizations are look= ing > for. Certainly a "loose promise" is not enough. Brian =20 > --Richard >=20 >=20 >=20 >> >> To be clear, I fully support the need for a professional fund-raiser, = in >> any of the models. >> >> Brian >> >>> >>> Alissa >>> >>> [1] https://datatracker.ietf.org/meeting/98/materials/minutes-98-iasa= 20/ >> = >>>> >>>> Brian >>>> >>>> _______________________________________________ >>>> iasa20 mailing list >>>> iasa20@ietf.org >>>> https://www.ietf.org/mailman/listinfo/iasa20 >>> >>> >> >> _______________________________________________ >> iasa20 mailing list >> iasa20@ietf.org >> https://www.ietf.org/mailman/listinfo/iasa20 >> >=20 From nobody Fri Nov 10 23:57:05 2017 Return-Path: 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 CE1CC1270B4 for ; Fri, 10 Nov 2017 23:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 t3ovSPgm0UNm for ; Fri, 10 Nov 2017 23:57:01 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A043C120726 for ; Fri, 10 Nov 2017 23:57:01 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id a84so3404630pfl.0 for ; Fri, 10 Nov 2017 23:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HbRdxWIX0jVJ6qMn//furvyfWEBtQbA6Xpkd+eNN3dw=; b=c8nTTw+m1gcSYmQ5AG9VzaVEIIi632Zcyz2XJK7eImBWO8+X1NuaaYTfTGKisc0Drf gJXRsEE5FHm4MypF04gsFXX2uDBD/I9ftNDeBHfSnXgQ5f4CjRTKJFv9susqdm76iQMP nQU5eNwWvquDbU/+sVKnc1jVw+MFyx2yvff68vX6CRMKOBRW8BxJ+p5mFz58CzHdCVQX 3DcVtAXr8z8+soEpsTxTiiGXl+6/dlTNWyLrYKZmoBrmEiUZvqpuKVEMJ4iQ095WA+08 8ctLXFLddzwmveAxissm6cR816V0QQ/glq4IZWRNy2BGMOPqUCgNPFKh+tLEPzksKB5N 5fVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HbRdxWIX0jVJ6qMn//furvyfWEBtQbA6Xpkd+eNN3dw=; b=kfhtOM0jtLV6Y65lanF5Hq9cEXRCDz36zbgj6KwXNG5EPjt/vefUVIIZG4yra/PiaS MPSEuBH8NewHFAJhklLwUS6tkL6ASU+yphSb0SqPiCkmJFhUCmdh1IsQL5Ni0SZ8thTq LXMWEPY7Qc4AmmJzkw8xggr4HWaahUxZwON7Ad+mmD3unuFqB+XSCnQA7eIMYPEaNGPw QjqnJu4/rfwpRZ8Cj4rNlKPtgtM+QHvyyqvG2dFatDM13/YRIHa9sn/QB/3ORtPxAyRw izPwcsL/tw0JsA6AHGp9sry8a+ncBtWaQ9mTVTjks8ebZ/L2KR90hlnO7MCDqXZ3AjVk f6/Q== X-Gm-Message-State: AJaThX6jt9XNNkjCH0TMcd0xAIuo2gvjzqKYY4ukYGqvTwPLBfDXRFtB IdBBXWNXuEhx3bD26eL4mSD3YL69 X-Google-Smtp-Source: AGs4zMYvgVb3Rqs5DIvE4jemWAEDEadLmIpLdDxrQe6dKZeP0gWKYHWR3Mxr6qpzM8RA8CMGmVA8WA== X-Received: by 10.84.240.204 with SMTP id l12mr2925804plt.211.1510387021015; Fri, 10 Nov 2017 23:57:01 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:f129:ab77:b36b:510c? ([2001:67c:1232:144:f129:ab77:b36b:510c]) by smtp.gmail.com with ESMTPSA id l1sm20421066pff.77.2017.11.10.23.56.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 23:56:59 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D482A627-5D4F-452F-B8AD-B3BD2C488F47"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 11 Nov 2017 15:56:57 +0800 In-Reply-To: <8B56C5FB-2402-47AC-893A-891ACF53814B@cooperw.in> Cc: Bob Hinden , iasa20@ietf.org To: Alissa Cooper References: <8B56C5FB-2402-47AC-893A-891ACF53814B@cooperw.in> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Comments on X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 07:57:04 -0000 --Apple-Mail=_D482A627-5D4F-452F-B8AD-B3BD2C488F47 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 H Alissa, > On Nov 10, 2017, at 11:15 AM, Alissa Cooper wrote: >=20 > Hi Bob, >=20 >> On Nov 8, 2017, at 8:51 AM, Bob Hinden wrote: >>=20 >> Hi, >>=20 >> Thanks for putting this together, I think it is an improvement over = the earlier version. >>=20 >> I have a lot of comments, but will stick with what I see is the high = level issue. >>=20 >> I think the basic conflict in the document is that it wants to not = make any change in how the IETF=E2=80=99s standardization works, but at = the same time wants to make the IETF more independent and in control of = what it does. I don=E2=80=99t think this is possible. We currently = have a model where financial decisions are kept very separate from the = standardization activities. When, for example, the IESG decides it = wants the IETF to do something it hasn=E2=80=99t done before, there is = never a discussion about how much does this cost and does it fit within = the budget. I use the IESG as an example, but it the same for the IAB, = IRTF, and RFC-Editor. >=20 > This doesn=E2=80=99t really match my experience. It=E2=80=99s true = that the budget is crafted and managed by different people than those = who make strategic decisions about standardization, architecture, and = research activities in the IETF/IRTF. But the IESG, and certainly the = IETF Chair, considers how much things cost all the time. For example, = last week I had a conversation with the secretariat about expenses = related to having multiple screens in the IETF meeting rooms. Within the = last couple of months the IESG had discussions about new MeetEcho = features we=E2=80=99d like to see, and the subject of cost came up both = in our conversation and as a gating factor requiring expenditure = approval before we could move forward. I personally think there are some = tools projects that I=E2=80=99d love to see done in the near term, but = since I know the tools budget is maxed out with the RFC format changes, = I haven=E2=80=99t initiated those conversations yet. Perhaps these are = smaller in value/cost than what you are thinking about (e.g., it=E2=80=99s= not like we cancel a meeting when we can=E2=80=99t find a host), but I = don=E2=80=99t think any of the leadership bodies operates as if there is = a bottomless well of money that can be spent if we so choose. That all good to hear, but I suspect that isn=E2=80=99t the case for the = other parts of the IETF like the IAB, RFC-Editor, and IRTF. I also = think that it wasn=E2=80=99t the case earlier. We tried pretty hard to = keep these things separate. >=20 > It is of course true that we don=E2=80=99t take strict measures to = stay within the bounds of what we budget each year. But I think the IETF = leadership already takes costs into consideration more often than you = suggest. My point is that if we want to be =E2=80=9Cindependent=E2=80=9D in = either model we will need to live within a real budget where we have to = make tradeoffs where to spend the money and to have the revenue and = expenses match. We have had the luxury to not have to do this until = now. It will require us to change how we operate. It will require = changes to how IETF standards operate in the operational sense, I would = like to the document make that clearer. As it is written that doesn=E2=80= =99t appear to be the case. Thanks, Bob >=20 > Alissa >=20 >=20 >> We have the luxury of operating this way because we know that ISOC = will pick up the extra costs. To make a very rough analogy, we are the = teenagers still living at home, but wanting complete independence and a = bigger allowance. Are we willing to move out, get a job, pay for an = apartment, etc. and become independent of our parents? I read a lot of = things in this document wanting to have it both ways. >>=20 >> If we want to be more independent (especially in the Subsidiary and = Independent models), I think this way of operating will need to change. = The IETF will have to become like an conventional organization where = finance is part of most decisions. For example, if the IESG decides to = add a new area, add ADs, add working groups, new tools, have an interim = meeting, or something else, it will need to know this fits in the = current budget. The IESG will need to have a budget, and live within = it=E2=80=99s budget. It will need to make the tradeoff between = something new and stopping some existing activity, or defer the new work = until more funding can be found. The IETFAdminOrg (staff and board) = won=E2=80=99t be able to do this because they don=E2=80=99t have enough = information to make good tradeoffs. More importantly, we will get = better decisions by having the IESG making these decisions. >>=20 >> If we don=E2=80=99t do something like this where finance is part of = what the IESG, IAB, RFC-Editor, and IRTF do, I don=E2=80=99t think we = will be able to move away from model where ISOC is the financial = backstop with everything else that comes along with this. Otherwise = we will continue to live in the world where we pretend that money = doesn=E2=80=99t exist. We can=E2=80=99t really become independent if we = continue to live in this world. >>=20 >> I think this will be necessary if we want to become an ISOC = Subsidiary or Independent organization. If we don=E2=80=99t want to do = this, then we should focus on improving and clarifying our relationship = with ISOC. Something like the IASA++ model. >>=20 >> I am not against the IETF becoming an ISOC Subsidiary (complete = Independence is not practical as far as I can tell), but think we need = to be realistic about what it means to do this. I don=E2=80=99t think = the changes can be limited to a separate IETFAdminOrg if we want it to = work. >>=20 >> Thanks, >> Bob >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> iasa20 mailing list >> iasa20@ietf.org >> https://www.ietf.org/mailman/listinfo/iasa20 >=20 --Apple-Mail=_D482A627-5D4F-452F-B8AD-B3BD2C488F47 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloGrUkACgkQrut0EXfn u6hfkggAmFJwB1kOtxjcuk3CeDCT1umEF0xNLPtUS/qq+yjCjtAq3wTn5NTiWX+8 YjV3XXI36qZ1m6SP9ia+ge6I6M/GMyNMtmDba9tvHyyCibiA6AC6yZ04AjNFS3i5 7BhhcLgMtAiSnFHjSORGLsQ69IDXF4O85XIfKTgU9Qlon9DQ+XUTaQrQl1pu2KlB lSR6XZzz9Y0X2laUUKxPJZQ2IPCOcFoAz2KV5HNLK8+9XoUgZgPxcakqEYIoVpJ1 xsdyY4ewHPP3DfeHrQ2EKeohfr+Ps264U7y9502KRhLgNfbK6zJlapTZdOxuWL3f aG1GFIeqLbQKb5wgbzTWO4qYeDVmoA== =1rn3 -----END PGP SIGNATURE----- --Apple-Mail=_D482A627-5D4F-452F-B8AD-B3BD2C488F47-- From nobody Sat Nov 11 00:50:26 2017 Return-Path: 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 8492312949D for ; Sat, 11 Nov 2017 00:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=QFAOa5+a; dkim=pass (1024-bit key) header.d=yitter.info header.b=OamjcrPA 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 iSeN5izfvPD3 for ; Sat, 11 Nov 2017 00:50:22 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBAA12420B for ; Sat, 11 Nov 2017 00:50:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 9BC99BF56B for ; Sat, 11 Nov 2017 08:50:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510390221; bh=uVP37vqXxOLqbnljtINrD0w2ZozbJfuasIYfl9pmn7A=; h=Date:From:To:Subject:References:In-Reply-To:From; b=QFAOa5+asdEbhkxzLhjcWbTxpfgfYT2rbCyL9teB9dReNqV8JSrTZvqnhagaoqKra 6onesjq21KTq/LbxA4Y9ottaWKsHsEtes8ejFmGg6SzX+irzF6DbwgqojaByOCoa8o s71lWJ0eEWjnJC22+tx7xRwbH0RvD2KZIaWRSfjA= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEFfwNxHPWC1 for ; Sat, 11 Nov 2017 08:50:20 +0000 (UTC) Date: Sat, 11 Nov 2017 03:50:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510390220; bh=uVP37vqXxOLqbnljtINrD0w2ZozbJfuasIYfl9pmn7A=; h=Date:From:To:Subject:References:In-Reply-To:From; b=OamjcrPA3TbEmErUv1NxjQefdU06j/hiGN69/svxjvjXj/oAXvhVujegG/YRCY3+R cQU7Hah5HRUkH1HtoUXhZVwKzY5vAc0ZIz3G4U0ICDjaS9tPKxv3v5uPGAJ2IG2bLT LG8xLvfwcY5OpYIOKIi8qgCdpTr4FL8KzPNVTK4M= From: Andrew Sullivan To: iasa20@ietf.org Message-ID: <20171111085016.xnuujlf33p7cjcxy@mx4.yitter.info> References: <8B56C5FB-2402-47AC-893A-891ACF53814B@cooperw.in> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Iasa20] Comments on X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 08:50:23 -0000 On Sat, Nov 11, 2017 at 03:56:57PM +0800, Bob Hinden wrote: > My point is that if we want to be “independent” in either model we will need to live within a real budget where we have to make tradeoffs where to spend the money and to have the revenue and expenses match. We have had the luxury to not have to do this until now. > I think that's probably true in a strict sense, but it seems to me that ought to be something to want _anyway_. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sat Nov 11 01:39:47 2017 Return-Path: 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 0FD77129490 for ; Sat, 11 Nov 2017 01:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Q7aEuJaaZ6Mu for ; Sat, 11 Nov 2017 01:39:44 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDEF129449 for ; Sat, 11 Nov 2017 01:39:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 699E92CE21; Sat, 11 Nov 2017 11:39:43 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHXo64QeZM_j; Sat, 11 Nov 2017 11:39:42 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 466582CD11; Sat, 11 Nov 2017 11:39:42 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Sat, 11 Nov 2017 17:39:39 +0800 Cc: iasa20@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171108214011.dpesoe4iz5gzaxfh@mx4.yitter.info> <28976c5c-9307-9079-9eb1-f7c791c16a89@gmail.com> <20171108221600.twlrk776mfjcciiw@mx4.yitter.info> To: Ted Hardie X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Some comments on draft-haberman-iasa20dt-recs-01 X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 09:39:46 -0000 > A mental model I find useful here is that of the "business unit". In = one corporate structure ... Thanks, Ted, I found the analogy quite useful. Jari From nobody Sun Nov 12 23:00:08 2017 Return-Path: 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 98AB9128D16 for ; Sun, 12 Nov 2017 23:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1qfZ5kQOD1mI for ; Sun, 12 Nov 2017 23:00:05 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEA8D12008A for ; Sun, 12 Nov 2017 23:00:04 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id u132so8191540ita.0 for ; Sun, 12 Nov 2017 23:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=i7lOSPVPJQeptGr3Yl54e50OKAqy20I23wKQKriKiwY=; b=r9h9MnRwJteU0k+ksCuAXXrNfPv8Du9nlqpERjQuBuT212xo0MwKf87dk7/JPORpc0 pOh2GWBIgV0YkqJerwAvEbG1GYQGf605UNVXseYb9de8IZwcvkCZABM2LsHYJ+yPRkl/ 58/ey3qSlY9bVM4wQxooX51D7baU++iNTTZvXwzpFLtofxyE60rp61zJXnDGC0f1UkbS 6Miyast3tzpLlJgYpfwYNazL6lXC1lqJgdCePAYrT4SfV4neIb85auYUFUarQ5lltim3 FK0lzpxRfw8VsPsisr9ZDlR7BTLfVRZtX1QjzDW6PmPyE27lxv3MihUQQW2183HCnSqA 7x9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=i7lOSPVPJQeptGr3Yl54e50OKAqy20I23wKQKriKiwY=; b=e6W7ZRLCLeBIkAmlBPOUCJNgcbhv/CmiySFwp4R6xMEfSCZ9IgfkjauHVfutlHwNWz 5BbFdLwCPdrFsTXeBsUWI9pHDmP0nOz9OWlWAIkQIoul8/PzEYq6hux1H+QJTOls+KeP lOy1ufTvAByeSgMnqEvR5K+foIHX9TBswurrkXQ5nH+WyqvNc+ryR4r3E7rbhwb+PjX9 8UtmYIMFIYXItdzm2JPGm6OO08CJnEH0bpxWxVTlA94YYmCpHAl+KJ0/xcwe18o08Hwb rSO1a7Wl0kM/Y2LKZo5pIlUFku0aKvO0MFBDCzCntPmkzsrtEJx7jxnflIMKQP1hkbv7 nIQQ== X-Gm-Message-State: AJaThX6Q3GMp2IQytDs68pNu5dDGIz+xfBMTMvxgzrhM+WNa/JoHRnWu hx0y3TSo044CmTsWi9THgUwhHIV9 X-Google-Smtp-Source: AGs4zMZ7QUSyyKdXIuMsR1r9Rnc8bB5huVajwnjEZPC3CsvBz8NhluSjW+0yeQr9h1SmMIdqMDeoEQ== X-Received: by 10.36.60.86 with SMTP id m83mr9048490ita.25.1510556404089; Sun, 12 Nov 2017 23:00:04 -0800 (PST) Received: from ?IPv6:2001:67c:370:1998:28cc:dc4c:9703:6781? ([2001:67c:370:1998:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g26sm6979263iob.34.2017.11.12.23.00.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 23:00:03 -0800 (PST) From: Brian E Carpenter To: Jari Arkko Cc: iasa20@ietf.org References: <150826730924.11473.15624020870916138544@ietfa.amsl.com> <2de8f0bd-6009-1375-c60d-4921a77e4d18@gmail.com> Organization: University of Auckland Message-ID: Date: Mon, 13 Nov 2017 19:59:59 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Iasa20] I-D Action: draft-haberman-iasa20dt-recs-01.txt X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 07:00:08 -0000 Jari, =2E..>>> 3.2.1. Volunteers >> ... >>> IETFAdminOrg must rely less on volunteers or be better assured of >>> engagement of willing and capable volunteers. >> >> I think this needs to be more explicit, e.g. >> >> IETFAdminOrg must rely less on volunteers or be better assured of >> engagement and formal commitments of willing and capable volunteers.= >> >> I believe somebody mentioned a while back that other professional >> bodies get their volunteers to sign a formal agreement. That may not >> be IETF-style but there's nothing worse than a vanishing volunteer=E2=80= =A6 >=20 > =E2=80=A6 except perhaps a volunteer that vanishes when you show the ag= reement :-) >=20 > Anyway, more seriously, do you have pointers to other organisations tha= t do this? Sorry, I don=E2=80=99t recall the previous discussion. I couldn't find the previous discussion, but Google found this which explains the concept. We might not need all the points, of course: https://knowhownonprofit.org/people/volunteers/keeping/volunteer-agreemen= ts# Brian From nobody Mon Nov 13 06:07:20 2017 Return-Path: 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 A4BED1296CF for ; Mon, 13 Nov 2017 06:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 ZqCA0OHBzeNj for ; Mon, 13 Nov 2017 06:07:18 -0800 (PST) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (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 A590C1296CD for ; Mon, 13 Nov 2017 06:07:18 -0800 (PST) X-AuditID: 60721c4b-477ff7000000bb69-0f-5a09a715c56e Received: from VAADCEX37.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 13.9E.47977.517A90A5; Mon, 13 Nov 2017 09:07:17 -0500 (EST) Received: from VAADCEX37.cable.comcast.com (147.191.103.214) by VAADCEX37.cable.comcast.com (147.191.103.214) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 13 Nov 2017 09:07:16 -0500 Received: from VAADCEX37.cable.comcast.com ([fe80::3aea:a7ff:fe12:38b0]) by VAADCEX37.cable.comcast.com ([fe80::3aea:a7ff:fe12:38b0%19]) with mapi id 15.00.1347.000; Mon, 13 Nov 2017 09:07:16 -0500 From: "Livingood, Jason" To: Bob Hinden , Alissa Cooper CC: "iasa20@ietf.org" Thread-Topic: [Iasa20] Comments on Thread-Index: AQHTWCuyC1jcimm9DkyAtoAng7EblaMNR+IAgAHg44CAA4wgAA== Date: Mon, 13 Nov 2017 14:07:16 +0000 Message-ID: <144EB2F9-427C-4D24-8CAD-7DA75DE8D584@cable.comcast.com> References: <8B56C5FB-2402-47AC-893A-891ACF53814B@cooperw.in> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.114.156.7] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPIsWRmVeSWpSXmKPExsWSUOxpoSu6nDPKYO1/E4vpZ/4yWmx9v4/N Ysn0jUwOzB5fnrxk8tg56y67x5IlP5kCmKO4bFJSczLLUov07RK4MvY1bWMpuMNV8eeJewPj Dq4uRk4OCQETiaNtq1m7GLk4hAS2M0lsfb+IHcI5xCixuG0xE4RzklFi4rtGFpAWNgEzibsL rzCD2CICHhI7njwHizMLqEv8PnOAEcQWFnCWaLuylhWixkVi5aI/TBC2k8TpnefBalgEVCU+ bV8L1ssLVLO65QhYjZDAYkaJ3r9A8zk4OAVsJVpn1YOEGQXEJL6fWsMEsUpc4taT+UwQHwhI LNlznhnCFpV4+fgf2FpRAT2J38deskPEdSTOXn/CCGEbSGxduo8FwlaQ6JkwHWwVs4CmxPpd +hDjrSSmXn3ODGErSkzpfsgOcaWgxMmZT6BaxSUOH9nBOoFRehaSi2YhTJqFZNIsJJNmIZm0 gJF1FSOPpZmeoaGJnpGFnrnpJkZQNBfJeO9gXPfT/RCjAAejEg+v1iTOKCHWxLLiylxgtHAw K4nwunUChXhTEiurUovy44tKc1KLDzFKc7AoifPOP8kaJSSQnliSmp2aWpBaBJNl4uCUamAs XJYU+XL7Wc/V599vtN+ydvv92dM7lTd/SlFaOZVL/PMRsYMSc1+c0DO4P3H+nz09Ko8+pfHf d/zD8nzLqtazP3Wm5nwVmn3+S6n8666Jx0++mlaYptukMtlK1atqx4/HXa/+dvTsT2NIrF13 jmeti8TvDK/bAtcdrWrrz/28fM7Kf8srOf2D1kosxRmJhlrMRcWJALCPizPiAgAA Archived-At: Subject: Re: [Iasa20] Comments on X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 14:07:19 -0000 WW91IG1ha2UgYSBnb29kIHBvaW50LCBCb2IuIEluIGEgbW9kZWwgd2hlcmUsIGZvciBleGFtcGxl LCB0aGUgSUVURiBoYXMgYW5udWFsIHJldmVudWVzIG9mICQzTSB0aGVuIHRoZSBvcmdhbml6YXRp b24gbXVzdCBjcmVhdGUgYSByZWFsaXN0aWMgYW5kIGFjaGlldmFibGUgYnVkZ2V0IGFuZCBsaXZl IHdpdGhpbiB0aGF0ICQzTS4gVHJhZGUtb2ZmcyBtdXN0IG5lY2Vzc2FyaWx5IGJlIG1hZGUgYW5k IHJlbGF0aXZlIHByaW9yaXRpZXMgc2V0LCBhcyBuZWl0aGVyIHRpbWUgbm9yIG1vbmV5IGFyZSB1 bmxpbWl0ZWQuIEkgdGhpbmsgdGhlIElFVEYgaXMgcmVhZHkgdG8gZG8gdGhhdC4gV2UgbWF5IGhh dmUgdG8gbGVhcm4gYSBsaXR0bGUgYml0IGFib3V0IHRoZSBmaW5hbmNpYWwgaW1wYWN0IG9mIHRo ZSBkZWNpc2lvbnMgd2UgbWFrZSBidXQgdGhhdCBzZWVtcyBhIG5hdHVyYWwgcGFydCBvZiB0aGUg bGVhcm5pbmcgcHJvY2VzcyBhbmQgdGhlIGRldmVsb3BtZW50IC8gbWF0dXJhdGlvbiBvZiB0aGUg SUVURuKAmXMgYWRtaW5pc3RyYXRpb24uDQoNCi0gSmFzb24NCg0KT24gMTEvMTEvMTcsIDI6NTcg QU0sICJpYXNhMjAgb24gYmVoYWxmIG9mIEJvYiBIaW5kZW4iIDxpYXNhMjAtYm91bmNlc0BpZXRm Lm9yZyBvbiBiZWhhbGYgb2YgYm9iLmhpbmRlbkBnbWFpbC5jb20+IHdyb3RlOg0KPiBNeSBwb2lu dCBpcyB0aGF0IGlmIHdlIHdhbnQgdG8gYmUg4oCcaW5kZXBlbmRlbnTigJ0gaW4gZWl0aGVyIG1v ZGVsIHdlIHdpbGwgbmVlZCB0byBsaXZlIHdpdGhpbiBhIHJlYWwgYnVkZ2V0IHdoZXJlIHdlIGhh dmUgdG8gbWFrZSB0cmFkZW9mZnMgd2hlcmUgdG8gc3BlbmQgdGhlIG1vbmV5IGFuZCB0byBoYXZl IHRoZSByZXZlbnVlIGFuZCBleHBlbnNlcyBtYXRjaC4gIFdlIGhhdmUgaGFkIHRoZSBsdXh1cnkg dG8gbm90IGhhdmUgdG8gZG8gdGhpcyB1bnRpbCBub3cuICBJdCB3aWxsIHJlcXVpcmUgdXMgdG8g Y2hhbmdlIGhvdyB3ZSBvcGVyYXRlLiAgIA0KIA0KDQo= From nobody Mon Nov 13 06:30:17 2017 Return-Path: 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 67E50129AA8 for ; Mon, 13 Nov 2017 06:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 nCqOZjsKgB4x for ; Mon, 13 Nov 2017 06:30:14 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 3433C129601 for ; Mon, 13 Nov 2017 06:30:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 204402CEC5; Mon, 13 Nov 2017 16:30:13 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9oW_PvhsCfO; Mon, 13 Nov 2017 16:30:12 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id DA7A82CD11; Mon, 13 Nov 2017 16:30:11 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Mon, 13 Nov 2017 22:30:09 +0800 Cc: Alissa Cooper , iasa20@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <73EA907F-55DF-4E7B-8BEB-6EAABBBA627B@piuha.net> References: <8B56C5FB-2402-47AC-893A-891ACF53814B@cooperw.in> To: Bob Hinden X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Comments on X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 14:30:16 -0000 Bob, One more follow-up: > My point is that if we want to be =E2=80=9Cindependent=E2=80=9D in = either model we will need to live within a real budget where we have to = make tradeoffs where to spend the money and to have the revenue and = expenses match. I=E2=80=99m not disagreeing, but I=E2=80=99ll point out what many have = already said: the options form a spectrum. It is true that for complete = independence one wants one=E2=80=99s own funding, everything under your = own control. And you could also imagine organisations where you have a = fixed budget, even if you shared employees with another entity. But I would hope that there are ways to improve organisation even (if) = its financial model stays the largely the same, or changes in smaller = degrees than going to full own funding. Our R&D department at the office = can reorganise itself even when the external funding situation stays the = same. I think the same applies to IETF. We=E2=80=99ve experienced some = pain in our current arrangements, at least in my experience. It would be = good to arrange our setup in the way that it works best for us. Jari From nobody Mon Nov 13 15:18:34 2017 Return-Path: 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 B1C60124E15 for ; Mon, 13 Nov 2017 15:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zgvV9I_uxELz for ; Mon, 13 Nov 2017 15:18:30 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3445120227 for ; Mon, 13 Nov 2017 15:18:30 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id d28so12968958pfe.2 for ; Mon, 13 Nov 2017 15:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VlAph89UHHF8VJxyxhdZ00vsurb2zfls0pp1P7MdBNU=; b=UEbPSa5C2xVBJLdvvmQgmtPtJ6V1iiCjk6qUXw4cvt5SA1MjYDFDJgH7NkAcMnHWYd 5dBQ80p4c4l1XrEBcKmy6Xw7wxrKezQ9kSFKE2gash4d8d5bHm0muP9ZQbCo9/QoAEjl lc2cKQxsDyFSXs2A7DucyomxuAaKhm7IGFBevTLJ064jRNVn5+JXd5hhVZ7PMRu9bOWq JeAi2qMvQdg2r2zUV8gciVLkLTH3lF9cxbS0LWsBGSYgTlKfPVo1CBjhGzOpKYASQquu VHGy14LJiI4XkL/3qPuQKfvzOw4mC7iJnXoLbDOGBsWOUTlrH1PuhLYiWJP+AmA1vUwH Y3Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=VlAph89UHHF8VJxyxhdZ00vsurb2zfls0pp1P7MdBNU=; b=sP4Vcnxb2ab69AlwpYLUOhbRg8mt1sDCpS9rD6FFla4s8S9fX6u5fc3fgFj9qVI27Y VPd2HUqxBalFY4AcSzdtCv0lTzAiWr0t5ccYZFHRqdcsuXULYsmgdO/CRqG0xHNBg/wM vmF0LBQ1fEqltwuBQOsaNZsYEN36y2qAZpKZCgeY42VDLXTDllLpTzR7W+LlfHe6iX5i MuT6f19OdXUbUpUOrnqTXEAUnFuPHavBeTIZ72LxLcdu3jqJQ0q4wMczeyy3B6L93ZsS JiM+4HMExAm6mt3LUJMUTzEODrcG8guEubaow0129TL2Cxg39Y5NsR3tCEAAfIavMWyK zA7Q== X-Gm-Message-State: AJaThX6JoB1yLO84xBtjQil37Q5aWL8ppfViJkOzFzsmKP2221dI7sXs pXLbL3IEMCY+eFz8VM+fvSdZEw== X-Google-Smtp-Source: AGs4zMZ/6bohlqwxr/qmIu+dEaVsLGYLu/5pjQFOTzqMPNGUvz9OsrlTXT55mm0jfCyBsahEVPmHGA== X-Received: by 10.99.119.15 with SMTP id s15mr10028288pgc.90.1510615109743; Mon, 13 Nov 2017 15:18:29 -0800 (PST) Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id 87sm23580832pfp.80.2017.11.13.15.18.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 15:18:28 -0800 (PST) To: "Livingood, Jason" , Bob Hinden , Alissa Cooper Cc: "iasa20@ietf.org" References: <8B56C5FB-2402-47AC-893A-891ACF53814B@cooperw.in> <144EB2F9-427C-4D24-8CAD-7DA75DE8D584@cable.comcast.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <828f542a-0ae1-8813-b3a0-2d03f317df9a@gmail.com> Date: Tue, 14 Nov 2017 12:18:26 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <144EB2F9-427C-4D24-8CAD-7DA75DE8D584@cable.comcast.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Iasa20] Comments on X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 23:18:33 -0000 On 14/11/2017 03:07, Livingood, Jason wrote: > You make a good point, Bob. In a model where, for example, the IETF has= annual revenues of $3M then the organization must create a realistic and= achievable budget and live within that $3M. Trade-offs must necessarily = be made and relative priorities set, as neither time nor money are unlimi= ted. I think the IETF is ready to do that. We may have to learn a little = bit about the financial impact of the decisions we make but that seems a = natural part of the learning process and the development / maturation of = the IETF=E2=80=99s administration. Right, but all that requires is a well-defined cost centre to which all IETF costs are assigned. It's a bit disappointing if that isn't already the case; since the IASA has been providing budget numbers to the communi= ty since 2006, I'm wondering what we are actually missing at the moment. Are we missing indirect costs that ISOC pays but doesn't charge back to the IETF budget? What is lacking at https://iaoc.ietf.org/budget-and-finance.html ? Brian >=20 > - Jason >=20 > On 11/11/17, 2:57 AM, "iasa20 on behalf of Bob Hinden" wrote: >> My point is that if we want to be =E2=80=9Cindependent=E2=80=9D in eit= her model we will need to live within a real budget where we have to make= tradeoffs where to spend the money and to have the revenue and expenses = match. We have had the luxury to not have to do this until now. It will= require us to change how we operate. =20 > =20 >=20 > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 >=20 From nobody Mon Nov 13 16:02:03 2017 Return-Path: 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 575DF12421A for ; Mon, 13 Nov 2017 16:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 TQPIuUTniZxz for ; Mon, 13 Nov 2017 16:01:58 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19D21200CF for ; Mon, 13 Nov 2017 16:01:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 48D80BE2E; Tue, 14 Nov 2017 00:01:56 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3SXhcT7Mma9; Tue, 14 Nov 2017 00:01:55 +0000 (GMT) Received: from [31.133.146.8] (dhcp-9208.meeting.ietf.org [31.133.146.8]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 588E9BDCC; Tue, 14 Nov 2017 00:01:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1510617715; bh=+hhf54IQxztoODHXahhZwPIB0u4Tdp9qAnC2dL1M1y8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=B2HtzjToJgQCzyXCnoMXColBAHnGF+wYugbYTCbMaoqQNPkN8HLCSP+iHbnVRQhQb DAW0wNDKGLaOxlEZF9aegc0qH0Ztkf0JQnPuNLh1vJ2H3QXW9FDZr0Aa/8/KIdeYF8 RiwHs7yibhiVYcqKXJJYb6N4tB1oUaHGRfsS+cl0= To: Jari Arkko , iasa20@ietf.org References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> Date: Tue, 14 Nov 2017 00:01:51 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="12ojSppAcNe7sS8pIlOJoa5EmsSvlMuUA" Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:02:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --12ojSppAcNe7sS8pIlOJoa5EmsSvlMuUA Content-Type: multipart/mixed; boundary="nTmQHqB8mjgEf2bwb0q2XuT3fTNJtfpNf"; protected-headers="v1" From: Stephen Farrell To: Jari Arkko , iasa20@ietf.org Message-ID: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> Subject: Re: [Iasa20] Thank you & we need your feedback References: In-Reply-To: --nTmQHqB8mjgEf2bwb0q2XuT3fTNJtfpNf Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, Thanks again to the DT for their work. Some additional feedback on the questions asked below. I've read the draft and recent list traffic and will try to not repeat things already said. I'll just provide my answer to this question: > o Which direction the community would like to take the work in > evolving IASA. I prefer that we pursue the IASA++ route. My main reasons are: - I think IASA++ allows us to fix what I see as the more pressing issues (transparency etc). I don't deny that there are other issues (fundraising) that might be better handled via the other options but I've not been convinced by the list traffic that fundraising or other issues better handled via the other options would be fatally undermined in the IASA++ scenario. IOW IASA++ seems to me good enough. - I think the subsidiary or independent organisation options will not be achievable in the next year - my takeaway from the IANA transition was that such changes will bring up so many issues that it'd add another year. That is my guess, others' guesses will no doubt differ but I think IASA++ has to be the smaller change and hence less complex. - I'm not keen on the IETF incorporating and like our current situation where anyone can contribute and nobody needs to be a member. I accept that some forms of ISOC subsidiary or independent organisation could preserve that but I fear that either of those approaches would over time lead to us ending up as a membership organisation. IMO the risk of us ending up there is lower with the IASA++ approach when I think about (i.e. guess;-) how things might evolve over the next 10 years, so for me that's a reason to fairly strongly prefer IASA++ Cheers, S. --nTmQHqB8mjgEf2bwb0q2XuT3fTNJtfpNf-- --12ojSppAcNe7sS8pIlOJoa5EmsSvlMuUA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaCjJvAAoJEC88hzaAX42ihAQH/ilCTydlvf9DGcLKtraS25ur j7bkzh083pgW3x20VSz770Reqq5jvVxVBMdD8ii7BuFuvtygiqcVLTBP1OC9UNmj aHC9+CDTh7ZjkTrZtKwPIk1+f6vBReuXSoeML4yNcgbO9H4JffV40gIAqUN8S1AE zqO2SVs/BYLPX3Cxygo5uZfp1YV81juvG37bgQbhKHnEjQxD9yxDQSvBXOXVafDL HaereUKqHg7XH7wg6tpIo8j4oivisPk7tkP6j0cgLuTa5+83S3tGV0TsRPjRkTGF q2oxVd5ACD0n8paNc2RVHJNFqAd8DGY4IHbNILkx2XyN/t17BCU9X08ar9Idp4M= =lzVc -----END PGP SIGNATURE----- --12ojSppAcNe7sS8pIlOJoa5EmsSvlMuUA-- From nobody Mon Nov 13 16:05:56 2017 Return-Path: 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 8C5D912421A for ; Mon, 13 Nov 2017 16:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 H9MZqm1nt037 for ; Mon, 13 Nov 2017 16:05:52 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64E512944E for ; Mon, 13 Nov 2017 16:05:40 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id q37so1244807ywa.12 for ; Mon, 13 Nov 2017 16:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rlyu4iTfPrrZAsuZJcAAfwcLxTV6dZEQAsZToRHDWbA=; b=vvOOCU2G2js5y4DXp6tSFEx54BlL+wBlIDtR6KaL6HR0Wv0zlDC67wi6EB12jcQKgM ol5XAHIgl0KwgOR6s2GI9s1RX085HwX7VzUwP34m/pFbnUcU5tgo4o+Dmh7TN4X8OaOS 94RWeQ0xo/SN4JarSEvuvh5G6ghPSEaq1Ojq+9MMszpjCNWTTBl8p7cGG4ZIZQmOQS9w EcYMSROcUs+CG1J+gevgXzrRAHF3QpkePu1mqGIo02qWI9LDpF6stMzfIJBGhnCT/MQu VJYeHrRLJvf7mvcC3v/4nOuzqhcjP5xH9DdEHIqtzk7QIsudk3f0O/qEceshpWtEXfpr aScw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rlyu4iTfPrrZAsuZJcAAfwcLxTV6dZEQAsZToRHDWbA=; b=ee2efv3mieC2ZGtve1JdF7C92LteMC3AMN5yTNK0MlRsU+nmMOq9eWZ+CFCLEaTrQv isZoB737vm8hEoGMuSTEm8L+OrFNJ3rPlpUBRHLAX8+AKgfoJGXRn4x6atc8SdV8MTdu gXIIvxEzc1m0rI++vlMgkrbVXrOEFc/vAcm8LEQkOJiYwFxQKBk5NljknakDh+I0wBXz aItR83eY97bg9lPu7uGWq0OxxKTlMHhZAoOzyTzuxWWZDapPqYl0/vzchs0UmVBUaEA7 MukVxsG9r8U492qP0xYJrb+fL1XbcAm2ic9fBTyo+0bGM9dTozHu9DERdS+TVANtx4ym tllA== X-Gm-Message-State: AJaThX79FGCwA+f7uVCh8H4BYb6d48ERBbrY2ke9ehb4w8OxCZ5CtbAq 8214cn9CruZcocWg1YmVhEMMmvlS1IOs6QTrsrUX1qU2 X-Google-Smtp-Source: AGs4zMZ+e4hUyeLl5dpOTeUaGbKw6tA/VaYiz7TDZnM1c6EWxG0CDAi5Tlob3qiGa4gwX2W22I9t2/PKy9hX9a/LjdI= X-Received: by 10.129.114.10 with SMTP id n10mr6773317ywc.327.1510617939901; Mon, 13 Nov 2017 16:05:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Mon, 13 Nov 2017 16:04:59 -0800 (PST) In-Reply-To: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> From: Eric Rescorla Date: Tue, 14 Nov 2017 00:04:59 +0000 Message-ID: To: Stephen Farrell Cc: Jari Arkko , iasa20@ietf.org Content-Type: multipart/alternative; boundary="001a11473894b3180f055de6258a" Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:05:54 -0000 --001a11473894b3180f055de6258a Content-Type: text/plain; charset="UTF-8" On Tue, Nov 14, 2017 at 12:01 AM, Stephen Farrell wrote: > > Hiya, > > Thanks again to the DT for their work. > > Some additional feedback on the questions asked below. I've read > the draft and recent list traffic and will try to not repeat things > already said. > > I'll just provide my answer to this question: > > > o Which direction the community would like to take the work in > > evolving IASA. > > I prefer that we pursue the IASA++ route. > > My main reasons are: > > - I think IASA++ allows us to fix what I see as the more pressing > issues (transparency etc). I don't deny that there are other > issues (fundraising) that might be better handled via the other > options but I've not been convinced by the list traffic that > fundraising or other issues better handled via the other options > would be fatally undermined in the IASA++ scenario. IOW IASA++ > seems to me good enough. > > - I think the subsidiary or independent organisation options will > not be achievable in the next year - my takeaway from the IANA > transition was that such changes will bring up so many issues that > it'd add another year. That is my guess, others' guesses will no > doubt differ but I think IASA++ has to be the smaller change and > hence less complex. > > - I'm not keen on the IETF incorporating and like our current > situation where anyone can contribute and nobody needs to be a > member. I accept that some forms of ISOC subsidiary or independent > organisation could preserve that Nothing we have proposed involves either (a) the IETF incorporating or (b) requiring people to be members. > but I fear that either of those > approaches would over time lead to us ending up as a membership > organisation. IMO the risk of us ending up there is lower with > the IASA++ approach when I think about (i.e. guess;-) how things > might evolve over the next 10 years, so for me that's a reason > to fairly strongly prefer IASA++ > OK, well, given that you don't actually provide any reason to believe that this will happen other than that you're anxious about it, I'm not really sure there's not much to usefully say here. -Ekr Cheers, > S. > > > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 > > --001a11473894b3180f055de6258a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 14, 2017 at 12:01 AM, Stephen Farrell <= ;stephen.far= rell@cs.tcd.ie> wrote:

Hiya,

Thanks again to the DT for their work.

Some additional feedback on the questions asked below. I've read
the draft and recent list traffic and will try to not repeat things
already said.

I'll just provide my answer to this question:

>=C2=A0 =C2=A0o=C2=A0 Which direction the community would like to take t= he work in
>=C2=A0 =C2=A0 =C2=A0 evolving IASA.

I prefer that we pursue the IASA++ route.

My main reasons are:

- I think IASA++ allows us to fix what I see as the more pressing
issues (transparency etc). I don't deny that there are other
issues (fundraising) that might be better handled via the other
options but I've not been convinced by the list traffic that
fundraising or other issues better handled via the other options
would be fatally undermined in the IASA++ scenario. IOW IASA++
seems to me good enough.

- I think the subsidiary or independent organisation options will
not be achievable in the next year - my takeaway from the IANA
transition was that such changes will bring up so many issues that
it'd add another year. That is my guess, others' guesses will no doubt differ but I think IASA++ has to be the smaller change and
hence less complex.

- I'm not keen on the IETF incorporating and like our current
situation where anyone can contribute and nobody needs to be a
member. I accept that some forms of ISOC subsidiary or independent
organisation could preserve that

Nothing w= e have proposed involves either (a) the IETF incorporating
or (b)= requiring people to be members.

=C2=A0
but I fear that either of those
approaches would over time lead to us ending up as a membership
organisation. IMO the risk of us ending up there is lower with
the IASA++ approach when I think about (i.e. guess;-) how things
might evolve over the next 10 years, so for me that's a reason
to fairly strongly prefer IASA++

OK, we= ll, given that you don't actually provide any reason to believe
that this will happen other than that you're anxious about it, I'= ;m not
really sure there's not much to usefully say here.

-Ekr

Cheers,
S.


_______________________________________________
iasa20 mailing list
iasa20@ietf.org
https://www.ietf.org/mailman/listinfo/iasa20

--001a11473894b3180f055de6258a-- From nobody Mon Nov 13 16:10:47 2017 Return-Path: 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 BA2561286AB for ; Mon, 13 Nov 2017 16:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 98b4wqknnk1w for ; Mon, 13 Nov 2017 16:10:44 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA3F412421A for ; Mon, 13 Nov 2017 16:10:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8A36DBE2E; Tue, 14 Nov 2017 00:10:42 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI-2cWfWTVNU; Tue, 14 Nov 2017 00:10:41 +0000 (GMT) Received: from [31.133.146.8] (dhcp-9208.meeting.ietf.org [31.133.146.8]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6DF05BDCC; Tue, 14 Nov 2017 00:10:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1510618241; bh=wxMI5C6c98H3OGvhKaBywP+3A3jZMSiT4FdX5ltZVb0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=k8SPWvgNILVZ9i3cMAdEZx9BHdnE+1z1a4iLcqPjRnbL2IvLYu0pFpjtIVyo7FSoU 2guzIHXIpQDPyFoy/+UNnn94y8OXwTxxFLXT4RbIoXXjWmjvACVaSDtO1SQcHGYwsH ycwj8GhSjg5KmktQ/TTw/jGOI7YRtFzqK1cer4qE= To: Eric Rescorla Cc: iasa20@ietf.org, Jari Arkko References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <8f6a64d0-38f5-efbb-7d20-1e7372d17e61@cs.tcd.ie> Date: Tue, 14 Nov 2017 00:10:37 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Bm99gJIsSTBK8thcE3CeWAbMxRVmVb54w" Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:10:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Bm99gJIsSTBK8thcE3CeWAbMxRVmVb54w Content-Type: multipart/mixed; boundary="C9FQuuvfr8mRNrRV10QGF3RPxrSg08gh9"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: iasa20@ietf.org, Jari Arkko Message-ID: <8f6a64d0-38f5-efbb-7d20-1e7372d17e61@cs.tcd.ie> Subject: Re: [Iasa20] Thank you & we need your feedback References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> In-Reply-To: --C9FQuuvfr8mRNrRV10QGF3RPxrSg08gh9 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 14/11/17 00:04, Eric Rescorla wrote: > OK, well, given that you don't actually provide any reason to believe > that this will happen other than that you're anxious about it, I'm not > really sure there's not much to usefully say here. Sorry, I thought it was fairly obvious: It seems to me to be in the nature of organisations to end up more, and not less, bureaucratic. I think a more bureaucratic organisation that could have members is more likely to end up requiring people to be members. Either of an ISOC subsidiary or independent organisation could impose membership as a requirement. IASA++ means that's less likely to happen. I think describing that as "anxiety" is trivialising what seems like a real risk. S. --C9FQuuvfr8mRNrRV10QGF3RPxrSg08gh9-- --Bm99gJIsSTBK8thcE3CeWAbMxRVmVb54w Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaCjR9AAoJEC88hzaAX42iE5MIAIV69r0L8fgLiZxPwIdKDobI tf4hwq+WyO0Dl6cQhfIyH5UTACgT2UP4D/adi/OOIAZHL2nLcM65kZAQ4ijgMpYK Z26NVrCeaLx7g6ZtJVPV/zNq3ragWk1WPx99l73IhgaPDc4DYC4cC8i4WkQqqyby R/L8pi8zLIFmcejLNXqb3XkwmK9mPgJg31+WbvNCqGaZTWAvkoJUWyfr4ZVcSFUV f07DEO2R7CobeQ5AU9bdKn4r4hyJS2Q47Nt7aWXdDQEcNU83Hms4KEhO+bFKDPpM Fa6fALmo89gc+1ueqeyHYGqxsXN0I+5A9fIZ64hVlYyNKa6g5dGuwq+F4clRtfk= =j5q8 -----END PGP SIGNATURE----- --Bm99gJIsSTBK8thcE3CeWAbMxRVmVb54w-- From nobody Mon Nov 13 16:15:42 2017 Return-Path: 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 981651288A9 for ; Mon, 13 Nov 2017 16:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 q9YhsxWIeHZx for ; Mon, 13 Nov 2017 16:15:39 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0295A1200CF for ; Mon, 13 Nov 2017 16:15:39 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id y75so15030172ywg.0 for ; Mon, 13 Nov 2017 16:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xC4oOxk0T0Fxr11rB0V7SkHNgmIQfGJrs05+ZcNI8lE=; b=lF/Q4VLjNt+0qPcXMQrOqvaggNsQP0z/XGlD/nBLumUhUwQRsOhM4xH8Sjjy1Ri9id j59JSWKYoK3j9isqzP4hne9rQhwccBbr4H9XobCA4NF+NaOijOL58QO6xV58Srnfzgid dN6xBqBy0ZABTNBx83bE98Yn+olczgn5aMHIJlEB1Ap6JIy3AZeudcsvOMhXpgdzODz+ MroEddveba8eOT5Getwc76hAh4vWnNbbEKB7oFqxV9C9smtjmwww0bE62dfbhA8Y6GN8 9KqRJylHHJ6tUS5SHRc4EMaB7zImY+998reeRyw5F4gO+ooEr1Is8dLdbcmlWNh5TwFj 6b/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xC4oOxk0T0Fxr11rB0V7SkHNgmIQfGJrs05+ZcNI8lE=; b=IeAdaJg93wvw5q2j5RHNg8T1RGyU9pmXke5qswE1lqqUoV2WDZIJ9m9L8gCs3kdWad XPpxpqAoWI2YZbQuWrdvKOKEcLCBgZWE0v5mywThpsSYTzzwNVAef5kGpqHVmDEByyh3 +jVLf4ifZErtIXJO9JwIojAqkYLYK3n/Q2xrFST8vIflXE7/pvzY5SF0sFcSP2fWRFw8 206smbRuQOgFsgQEgakpKHpB4zgL/bO3A2dX3d6Oy+lvpUJDzw8XNLB+2US/wchMXHQR 9ZJbYgGaoTZ3xe+ur169OSKib3LAmj8e9gz2x8u1vWnrPRUYEg4QxkZOc7T9zQqygC96 q4iQ== X-Gm-Message-State: AJaThX5D5Lwxw/41B6VLVPNLSexAoFLqM3AG8evER4RvTakr6Ukw/RRB 8r841We3Sml0at9Edor9coHTO9cZzBZdQnGj3KcD6gs+gVE= X-Google-Smtp-Source: AGs4zMb+Fi3IpOLnHzrR7SqcHLsrIhiCgKEDLofWpmpKaONZJ3AL1CHGHkSEbdFXp5PMwrMm70okTeL5Nq5B2CtW+4c= X-Received: by 10.37.20.193 with SMTP id 184mr6347472ybu.400.1510618538127; Mon, 13 Nov 2017 16:15:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Mon, 13 Nov 2017 16:14:57 -0800 (PST) In-Reply-To: <8f6a64d0-38f5-efbb-7d20-1e7372d17e61@cs.tcd.ie> References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> <8f6a64d0-38f5-efbb-7d20-1e7372d17e61@cs.tcd.ie> From: Eric Rescorla Date: Tue, 14 Nov 2017 00:14:57 +0000 Message-ID: To: Stephen Farrell Cc: iasa20@ietf.org, Jari Arkko Content-Type: multipart/alternative; boundary="001a113e72b65b6486055de6490b" Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:15:41 -0000 --001a113e72b65b6486055de6490b Content-Type: text/plain; charset="UTF-8" On Tue, Nov 14, 2017 at 12:10 AM, Stephen Farrell wrote: > > > On 14/11/17 00:04, Eric Rescorla wrote: > > OK, well, given that you don't actually provide any reason to believe > > that this will happen other than that you're anxious about it, I'm not > > really sure there's not much to usefully say here. > > Sorry, I thought it was fairly obvious: > > It seems to me to be in the nature of organisations to end > up more, and not less, bureaucratic. I think a more bureaucratic > organisation that could have members is more likely to end up > requiring people to be members. Either of an ISOC subsidiary > or independent organisation could impose membership as a > requirement. IASA++ means that's less likely to happen. > It's not at all clear to me that this is the case, given that ISOC *already* has members [0] and it would therefore be trivial to require IETF participants to be ISOC members. I think describing that as "anxiety" is trivialising what > seems like a real risk. > "seems" is doing a lot of work here. It may seem like a real risk to you but it doesn't seem like a real risk to me, and your text above doesn't do much to persuade me. -Ekr [0] https://www.isoc.org/membership/rules.shtml > S. > > > --001a113e72b65b6486055de6490b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 14, 2017 at 12:10 AM, Stephen Farrell <= ;stephen.far= rell@cs.tcd.ie> wrote:


On 14/11/17 00:04, Eric Rescorla wrote:
> OK, well, given that you don't actually provide any reason to beli= eve
> that this will happen other than that you're anxious about it, I&#= 39;m not
> really sure there's not much to usefully say here.

Sorry, I thought it was fairly obvious:

It seems to me to be in the nature of organisations to end
up more, and not less, bureaucratic. I think a more bureaucratic
organisation that could have members is more likely to end up
requiring people to be members. Either of an ISOC subsidiary
or independent organisation could impose membership as a
requirement. IASA++ means that's less likely to happen.

It's not at all clear to me that this is the case,= given that ISOC *already*
has members [0] and it would therefore= be trivial to require IETF participants
to be ISOC members.


I think describing that as "anxiety" is trivialising what
seems like a real risk.

"seems&quo= t; is doing a lot of work here. It may seem like a real risk to you
but it doesn't seem like a real risk to me, and your text above does= n't do
much to persuade me.

--001a113e72b65b6486055de6490b-- From nobody Mon Nov 13 16:20:29 2017 Return-Path: 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 2A6651292AE for ; Mon, 13 Nov 2017 16:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 NMTCGkx1iF_s for ; Mon, 13 Nov 2017 16:20:25 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65E1F128D0F for ; Mon, 13 Nov 2017 16:20:25 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id t69so4080286pfg.4 for ; Mon, 13 Nov 2017 16:20:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Bgkm109TMuPzAuU5X3MP26UMoKnq5Tds7sfCW/xSu7Y=; b=hMimW47KWl8oXAnDVT9r69bU+f+94Xfsq+aQ+ACjhb0+IW+rRUtnjAAu0RghlbU2Bk Drbj16wCkJ14bMtY6ehqIJbjujFDbjFnBFPcl1bK4SgAmuFpr7T4vyjULzHRExiwC94o MVDhgOVSYbafyTPZJ480Q20axyKsEIMCuBzx5fOrLqV7D0OaBDrQy3ozpGM+dHbcio84 a74xNQ4wQp7tk20xqCce+EO+NC3AaKRIZcjg7Qnmu2OT/FjFKSD0cxOfSw6m0jLY7dTN 4w3HsXBQXaWX9whlAzZ7CwvOw43NkFdopvht8RQ5Pn5tD5vu8erOuN8+00Td8lwKMruH 9+xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=Bgkm109TMuPzAuU5X3MP26UMoKnq5Tds7sfCW/xSu7Y=; b=jZfDiliNY3JNER1QrXmWavxFWAbTNSk3VHUo0FqehAwJPDcLDals/1tsj5PFkg30ga 9KgV/mb0ZpCu6JZSfJjgwvDIwio261rsHQcp6af2vkuomA15Vofy96k7cKZGZyj5ou0J pEoC/49atmhUxiJXeZ0GpU+6J991Ivo5kUMQXrxcy9FTenzSOP2g9L7VgqOu63JYDJiv //+MehtkfrXxK1MKO4YEocHlbi1ckUByORLRjBCwMi002UcurVbGQe3x8nEck7VLnIo8 lt4DNqyX6QcyopHpx75f9j0YoybmCABxcgRnhJrwzkm2BtNNUvrP8gwae1HeWbmtG/qv aRSA== X-Gm-Message-State: AJaThX4eqI68URolruAeGIqy659QlEkVRfL1WzvJ/ROAQoIbp0imPwHs i5+4LQu3CsnB3nJ5CKbKVQfyUw== X-Google-Smtp-Source: AGs4zMZQVOl+PyFh5zR5L9+qNbhEy43jHrtNE54raE+Mw54STiSdvEnOuRfOvZzuLxqr9aXb30bOww== X-Received: by 10.99.54.130 with SMTP id d124mr1521447pga.108.1510618824691; Mon, 13 Nov 2017 16:20:24 -0800 (PST) Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id p87sm18997060pfi.95.2017.11.13.16.20.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 16:20:23 -0800 (PST) To: iasa20@ietf.org References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> <8f6a64d0-38f5-efbb-7d20-1e7372d17e61@cs.tcd.ie> From: Brian E Carpenter Organization: University of Auckland Message-ID: <12f446e4-2969-6924-fd70-2afde56b8db6@gmail.com> Date: Tue, 14 Nov 2017 13:20:22 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <8f6a64d0-38f5-efbb-7d20-1e7372d17e61@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:20:27 -0000 Stephen, On 14/11/2017 13:10, Stephen Farrell wrote: > > > On 14/11/17 00:04, Eric Rescorla wrote: >> OK, well, given that you don't actually provide any reason to believe >> that this will happen other than that you're anxious about it, I'm not >> really sure there's not much to usefully say here. > > Sorry, I thought it was fairly obvious: > > It seems to me to be in the nature of organisations to end > up more, and not less, bureaucratic. I think a more bureaucratic > organisation that could have members is more likely to end up > requiring people to be members. Either of an ISOC subsidiary > or independent organisation could impose membership as a > requirement. IASA++ means that's less likely to happen. > > I think describing that as "anxiety" is trivialising what > seems like a real risk. I think ekr's right, this is not a real risk. The real risk is that either of the incorporation models creates bureaucracy but either does not solve the underlying problems better than IASA++ would do, or leads to alternative problems after a few years. The alternative problems are probably best described as "ICANNitis", in other words an organization that develops a dynamic of its own that its stakeholders don't like. Brian > > S. > > > > > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 > From nobody Mon Nov 13 16:21:03 2017 Return-Path: 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 00302128D0F for ; Mon, 13 Nov 2017 16:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 s3btsWglbMUh for ; Mon, 13 Nov 2017 16:21:01 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id EA627128954 for ; Mon, 13 Nov 2017 16:21:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 441602CE21; Tue, 14 Nov 2017 02:20:59 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgfkLx1sXRXy; Tue, 14 Nov 2017 02:20:57 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 182872CD11; Tue, 14 Nov 2017 02:20:56 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> Date: Tue, 14 Nov 2017 08:20:55 +0800 Cc: iasa20@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <58452E9F-F707-4430-96B5-CE80ED8813D8@piuha.net> References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:21:03 -0000 Stephen: Thanks. And your concern was a big basis for us to be careful about what we are = doing here. Specifically, keeping IETF (incl. participants, WGs, IESG, = etc) and IETFAdminOrg separate. Can you speak to how clearly that comes = out of the document, and to what extent that helps keep your worry in = check? Jari From nobody Mon Nov 13 16:24:10 2017 Return-Path: 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 AEFD5126CD6 for ; Mon, 13 Nov 2017 16:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 vw5Z7qVZGukr for ; Mon, 13 Nov 2017 16:24:06 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD231200CF for ; Mon, 13 Nov 2017 16:24:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1DE4ABE2E; Tue, 14 Nov 2017 00:24:05 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvf8xQ-EK3sg; Tue, 14 Nov 2017 00:24:03 +0000 (GMT) Received: from [31.133.146.8] (dhcp-9208.meeting.ietf.org [31.133.146.8]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5EAA3BDCC; Tue, 14 Nov 2017 00:24:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1510619043; bh=0X1eOnErXlW3JQvMu3IKHceS7+ytXa1dng5dROyUzo4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ekut5LlLAEZ+tn8G5qsztOMWjEHA+/TP566/TN9vq72LTRwNpg9+WJS6aupgup8/Y cr5kECa8oFxWSEXUIKelQYvrdc7j9clrFVQoj5AI4VzFphiuJ+RY82mdl2oImhcPjj PmPK+DJQ9zBMgggRv/k18PvdoXLU1P3ires/VUNw= To: Eric Rescorla Cc: iasa20@ietf.org, Jari Arkko References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> <8f6a64d0-38f5-efbb-7d20-1e7372d17e61@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 14 Nov 2017 00:23:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bnGbxGQ19jSo9sgXRDGwWirSliv5Fm3gL" Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:24:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bnGbxGQ19jSo9sgXRDGwWirSliv5Fm3gL Content-Type: multipart/mixed; boundary="9EN2iudMjmEmRsJGqIEO3VoweWDI0hxU7"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: iasa20@ietf.org, Jari Arkko Message-ID: Subject: Re: [Iasa20] Thank you & we need your feedback References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> <8f6a64d0-38f5-efbb-7d20-1e7372d17e61@cs.tcd.ie> In-Reply-To: --9EN2iudMjmEmRsJGqIEO3VoweWDI0hxU7 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 14/11/17 00:14, Eric Rescorla wrote: > On Tue, Nov 14, 2017 at 12:10 AM, Stephen Farrell > wrote: >=20 >> >> >> On 14/11/17 00:04, Eric Rescorla wrote: >>> OK, well, given that you don't actually provide any reason to believe= >>> that this will happen other than that you're anxious about it, I'm no= t >>> really sure there's not much to usefully say here. >> >> Sorry, I thought it was fairly obvious: >> >> It seems to me to be in the nature of organisations to end >> up more, and not less, bureaucratic. I think a more bureaucratic >> organisation that could have members is more likely to end up >> requiring people to be members. Either of an ISOC subsidiary >> or independent organisation could impose membership as a >> requirement. IASA++ means that's less likely to happen. >> >=20 > It's not at all clear to me that this is the case, given that ISOC *alr= eady* > has members [0] and it would therefore be trivial to require IETF > participants > to be ISOC members. I don't think that'd be at all trivial. The community would, I think, be quite likely to strongly resist such an attempt. (I would anyway, and I don't think I'd be alone:-). Changing our processes to ignore such community input/resistance would require changing a bunch of BCPs which is never trivial. >=20 >=20 > I think describing that as "anxiety" is trivialising what >> seems like a real risk. >> >=20 > "seems" is doing a lot of work here. It may seem like a real risk to yo= u > but it doesn't seem like a real risk to me, and your text above doesn't= do > much to persuade me. Sure, I'm not saying that mine is a killer argument. I'm also not saying anything is inevitable, and it's fine that we evaluate the risk differently as there can't be any certainties here. But, my evaluation of that risk remains one of the reasons I personally prefer IASA++ as of now. S. >=20 > -Ekr >=20 > [0] https://www.isoc.org/membership/rules.shtml >=20 >=20 >> S. >> >> >> >=20 >=20 >=20 > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 >=20 --9EN2iudMjmEmRsJGqIEO3VoweWDI0hxU7-- --bnGbxGQ19jSo9sgXRDGwWirSliv5Fm3gL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaCjefAAoJEC88hzaAX42iTW4IAKuPGhFKz00tJ1BJrjXN47pk R21v/qdGM0I34dHr920FGArgLvVZbi6jOUMhttWFQ251wHij6I7TDIvM1xKCQr4l PLGf+jWRPtLe2eJGiU3lBuRsWpsi7aViPreXzlOd4AWO41TT0kmugMVcXJxK8lw9 yIZy0s8lzBvG8Jhf2CkbFFr6XHjn/8U49dWWMFHO0csss5XSi+e0Vj2saVVst02t HM9BGuL9oHCnUHW8E9T0d6T02K/hL4bTLrT9CYPqmsBre2qozCys8Nb/eZZXGhrt jVUSLEydOJSx3vjHGaLB8gSzhH0eKFI6EpBvFQhbBfwFXLdFpWDkhwYxy2zM70E= =eYbl -----END PGP SIGNATURE----- --bnGbxGQ19jSo9sgXRDGwWirSliv5Fm3gL-- From nobody Mon Nov 13 16:24:24 2017 Return-Path: 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 623131292AE for ; Mon, 13 Nov 2017 16:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 7ZImr2rDcBiH for ; Mon, 13 Nov 2017 16:24:14 -0800 (PST) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (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 D86441200CF for ; Mon, 13 Nov 2017 16:24:13 -0800 (PST) X-AuditID: 60721c4b-477ff7000000bb69-64-5a0a37accd64 Received: from VAADCEX37.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id A6.2E.47977.CA73A0A5; Mon, 13 Nov 2017 19:24:12 -0500 (EST) Received: from VAADCEX37.cable.comcast.com (147.191.103.214) by VAADCEX37.cable.comcast.com (147.191.103.214) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 13 Nov 2017 19:24:11 -0500 Received: from VAADCEX37.cable.comcast.com ([fe80::3aea:a7ff:fe12:38b0]) by VAADCEX37.cable.comcast.com ([fe80::3aea:a7ff:fe12:38b0%19]) with mapi id 15.00.1347.000; Mon, 13 Nov 2017 19:24:11 -0500 From: "Livingood, Jason" To: Stephen Farrell , Jari Arkko , "iasa20@ietf.org" Thread-Topic: [Iasa20] Thank you & we need your feedback Thread-Index: AQHTUzprvL7aLSzwAEuti99qDdJT7qMTZOiAgAAGPYA= Date: Tue, 14 Nov 2017 00:24:11 +0000 Message-ID: <596586DD-785D-4B84-AD71-295664508037@cable.comcast.com> References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> In-Reply-To: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.114.156.9] Content-Type: text/plain; charset="utf-8" Content-ID: <907423E1616AAF4D9A7B1CBDE7BD347F@comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCIsWRmVeSWpSXmKPExsWSUOxpobvGnCvK4MNfM4sl0zcyWczYt4LN Yvrea+wOzB5ru6+yeSxZ8pPJY+uS6WwBzFFcNimpOZllqUX6dglcGdMWf2Uq6OOvmN/yiLmB 8Q5fFyMnh4SAicSN18tYuxi5OIQEtjNJdHStZoNwDjFKtJ98zwThnGSU2HXyDRNIC5uAmcTd hVeYQWwRgUqJtnnv2bsYOTiEBcwlNr5KgQhbSPz/Nw+qxEpixvxZYDaLgKrErYXvGEFsXgEX iY5fv8FsIYF8iRNfWllBbE4BW4mPB96D2YwCYhLfT60BW8ssIC5x68l8JoirBSSW7DnPDGGL Srx8/A+sXlRAT+L3sZfsEHEdibPXnzBC2AYSW5fuY4GwFSTe/zvFBnIys4CmxPpd+hDjrSSe fTnIBmErSkzpfsgOcaagxMmZT6BaxSUOH9nBOoFRahaSi2YhTJqFZNIsJJNmIZm0gJF1FSOP pZmeoaGJnpGFnrnpJkZQ3BbJeO9gXPfT/RCjAAejEg9viCJXlBBrYllxZS4wKjiYlUR4LXiB QrwpiZVVqUX58UWlOanFhxilOViUxHnnn2SNEhJITyxJzU5NLUgtgskycXBKNTC6RErwTUx3 2vNxoqxka/z8kvDfNe71Vxh2Wp0TOJp9vsBmlUv/paogB3Hnt+HKG2ry9lle1jYvtVV7JJ5+ 9+N32b6th6qOWCg/1rXf+39vs0zD5wklhkd+TN9ad6P2mQKft/sNZZOb/XJyr7mCmWR3V0pf OFU849o26cuaop8Xx7etXPtf+oISS3FGoqEWc1FxIgAdDBQo1wIAAA== Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:24:16 -0000 T24gMTEvMTMvMTcsIDc6MDIgUE0sICJpYXNhMjAgb24gYmVoYWxmIG9mIFN0ZXBoZW4gRmFycmVs bCIgPGlhc2EyMC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllPiB3cm90ZToNCg0KPiBJIGRvbid0IGRlbnkgdGhhdCB0aGVyZSBhcmUgb3RoZXIN CiAgICBpc3N1ZXMgKGZ1bmRyYWlzaW5nKSB0aGF0IG1pZ2h0IGJlIGJldHRlciBoYW5kbGVkIHZp YSB0aGUgb3RoZXINCiAgICBvcHRpb25zIGJ1dCBJJ3ZlIG5vdCBiZWVuIGNvbnZpbmNlZCBieSB0 aGUgbGlzdCB0cmFmZmljIHRoYXQNCiAgICBmdW5kcmFpc2luZyBvciBvdGhlciBpc3N1ZXMgYmV0 dGVyIGhhbmRsZWQgdmlhIHRoZSBvdGhlciBvcHRpb25zDQogICAgd291bGQgYmUgZmF0YWxseSB1 bmRlcm1pbmVkIGluIHRoZSBJQVNBKysgc2NlbmFyaW8uIA0KDQpbSkxdIEkgbm90aWNlZCBhIG51 bWJlciBvZiB0aGUgZ2xvYmFsIHNwb25zb3JzIGF0IHRoZSBsYXN0IG1lZXRpbmcgYW5kIG9uIHRo aXMgbGlzdCBzdWdnZXN0aW5nIG90aGVyd2lzZSAodGhhdCB0aGUgY3VycmVudCBhcHByb2FjaCBp cyBwcm9ibGVtYXRpYykuIA0KDQo+IEkgdGhpbmsgdGhlIHN1YnNpZGlhcnkgb3IgaW5kZXBlbmRl bnQgb3JnYW5pc2F0aW9uIG9wdGlvbnMgd2lsbA0KICAgIG5vdCBiZSBhY2hpZXZhYmxlIGluIHRo ZSBuZXh0IHllYXIgDQoNCltKTF0gSSBhZ3JlZSB3aXRoIHlvdXIgc2VudGltZW50IHRoYXQgd2Ug bXVzdCBzdHJpa2UgYSBiYWxhbmNlIOKAkyB3ZSBkb27igJl0IHdhbnQgdG8gc3BlbmQgeWVhcnMg YW5kIHllYXJzIG9uIHRoaXMgYnV0IGF0IHRoZSBzYW1lIHRpbWUgaXTigJlkIGJlIHVuZm9ydHVu YXRlIHRvIGJlIGJhY2sgZGlzY3Vzc2luZyBhIG5ldyBhcHByb2FjaCBpbiBqdXN0IGEgZmV3IHll YXJzIHRpbWUuIFNvIEkgZ3Vlc3MgdGhlIGtleSBpcyB0byBnZXQgdG8gdGhlIHJpZ2h0IGFkbWlu aXN0cmF0aXZlIG1vZGVsIHRoYXQgd2lsbCBsYXN0IHRoZSBJRVRGIGFub3RoZXIgMTAgeWVhcnMg b3IgbXVjaCBsb25nZXIsIGJ1dCBub3QgdGFrZSB1cCB5ZWFycyBvZiB0aW1lIGRvaW5nIHNvLg0K CQ0KPiBJJ20gbm90IGtlZW4gb24gdGhlIElFVEYgaW5jb3Jwb3JhdGluZyBhbmQgbGlrZSBvdXIg Y3VycmVudA0KICAgIHNpdHVhdGlvbiB3aGVyZSBhbnlvbmUgY2FuIGNvbnRyaWJ1dGUgYW5kIG5v Ym9keSBuZWVkcyB0byBiZSBhDQogICAgbWVtYmVyLiANCg0KW0pMXSBUaGUgYWRtaW5pc3RyYXRp dmUgb3B0aW9ucyB0aGUgRFQgaGFzIGJlZW4gY29uc2lkZXJpbmcgd291bGQgbm90IGNoYW5nZSB0 aGUgcGFydGljaXBhdGlvbiBtb2RlbC4gSW5kZWVkIOKAkyBwcmVzZXJ2aW5nIGl0IGlzIGxpc3Rl ZCBhcyBvbmUgb2YgdGhlIGtleSBnb2Fscy4NCg0KDQoNCiAgICANCg0KDQo= From nobody Mon Nov 13 16:29:07 2017 Return-Path: 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 D817E128954 for ; Mon, 13 Nov 2017 16:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 kdF8rtsuc4Pf for ; Mon, 13 Nov 2017 16:29:04 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 86DDF1200CF for ; Mon, 13 Nov 2017 16:29:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BC9752CE21 for ; Tue, 14 Nov 2017 02:29:01 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umITpDoKjIIu for ; Tue, 14 Nov 2017 02:29:01 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 6B0BB2CD11 for ; Tue, 14 Nov 2017 02:29:00 +0200 (EET) (envelope-from jari.arkko@piuha.net) From: Jari Arkko Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <583DA439-F8F6-43FB-B7AC-BC33354F2CFA@piuha.net> Date: Tue, 14 Nov 2017 08:28:58 +0800 To: iasa20@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Iasa20] Summary of feedback so far X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:29:06 -0000 This is a quick summary from my perspective on the kinds of things = we=E2=80=99ve heard from you, on and off list: On options: ----------- Several people commented that the three options on display here as = points along a trajectory or spectrum. The main question has been between IASA++ and the subsidiary options, = essentially about whether the focus should be about ``Having a clear organizational = boundary'' vs. ``Avoiding a subsidiary organization as that just adds bureaucracy = and distance from funding source''. Or, should we be solving specific problematic issues = or should we be evolving basic organisational design to reduce issues? Other comments: - For any IETF independence or even for the subsidiary model, IETF has = to become aware of costs. Cannot separate administrative operations from IESG, IAB, etc. - Is there really a lot of difference between the subsidiary and = independent cases as long as ISOC is primary funder? - Clear separation of the accounts and of decision making concerning = those accounts is one of the fixes needed for IASA++, and that should be enough. - The IETF needs to be able to make its own administrative decisions = independent of ISOC." If we take this to be true, then IASA++ is simply not an option. = Currently we only have an informal agreeement with ISOC. - Legal roles matter. If final authority is ISOC's, that does not seem = like it meets the autonomy and accountability goals we have here. - We can use business analogy here. Folks believe that we need the "IETF = line of business" to operate in a way that is different from other work done by ISOC. = We need to be transparent in specific ways, and we need to take into account the = specific needs of developing our standards. This document lays out three ways to = accomplish it. - A detail here, but the subsidiary and independent organisations would = need to apply for non-profit status. On ISOC relationship: --------------------- Some commonly believed observations here seem to be first of all that as = long as the IETF is largely reliant on ISOC for funding, ISOC will have a degree of = control regardless of formal independence. And secondly, that it is important to retain close = relationship with ISOC. The main discussion (beyond the formal creation of subsidiaries etc) has = been to which extent should the subsidiary or independent options change the way IETF = does budgeting or funding. For instance, do these models imply a fixed budget or the = on-a-need-basis type of funding that IETF currently gets from ISOC? Other comemnts: - IASA++ could be seen as a stronger integration with ISOC (which could = also be a good thing); this isn=E2=80=99t described in the document. - Legal constraints are there regardless of IETFAdminOrg decisions. = Unless there is total separation, ISOC will continue to bear some risks, for instance. But = of course IETFAdminOrg should have appropriate authority; in my opinion this = hasn't been a problem in the past though. - Specifying how future evolution in the interface happens is important. = For instance, the option (in Section 5.1.2) of ISOC re-absorbing the functions if the = arrangements are finished needs further discussion, who can do that, etc. On staff: --------- Here there has been first of all some discussion of the practicalities = of employee performance review and other managerial processes, who owns these = processes, and whether there are barriers (e.g., legal) to how much IETF admistrative side can = do. One comment we received worried about the the bigger role of staff or = contractors and the increased number of people working for the IETF. Will staff's role and = decisions be too central? Some of the growth seems unavoidable, though, increasing work, = limited availability of volunteer cycles, etc. It is critical to ensure our = oversight, control, roles are clear. The main question is limiting staff/contractor growth = vs. organising them for best IETF-community oversight and control. Other comments: - Question about the need for Communications Director position, or the = director-levelness of that position. On IETF Trust: -------------- Several people have commented here that the IETF Trust is a whole = different discussion, details deserve further thought. E.g., that the evolution of the IETF = Trust will be addressed separately at a later date. On IETF vs. IETFAdminOrg roles: ------------------------------- Here we have mainly received some questions and requests for = clarification. For instance, about the difference between IETFAdminOrg and IETF, and why the document = emphasized that? (The design team felt it is important to underline that what IETF = administration continues to do has no impact on the standards side of the house.) We also heard that the role of IETF chair vs. IETFAdminOrg Executive = Director needs more clear separation. We also got a comment that the goal text around avoiding overloading = community volunteers is well formulated. On funding: ----------- Here we've had some discussions about whether the nature of the = administrative organisation changes the budgeting process or the type of funding (e.g., = fixed or on a per-need-basis) that we get. In addition, we received a comment that there is a need an IETF-ISOC = agreement on funding even for IASA++, lack of this agreement is what is causing current = unclarities. =20 Other comments: - Would like to talk about more predictable level of funding overall, = not just from ISOC. On Advisory Council: -------------------- We've received a question on this, whether it is an extra layer or = actually needed. On transparency: ---------------- Not much discussion of this yet, presume there will be more as this has = been an important issue for the community. We did receive one comment the goal related to = this is well formulated. On volunteers: -------------- Not much discussion of this either, but we did receive a comment that we = should consider formal commitment from volunteers. Comparisons: ------------ Here we received feedback e.g., about corrections relating to funding = arrangements and staff and making those comparisons fairer for the IASA++ option. Missing: -------- Some missing things: - If there's going to be a new entity, where it falls on the = subsidiary/independent spectrum will depend largely on (1) how its board is formed, and (2) = what resources it shares with ISOC. So it may make more sense to focus more directly on = these questions. - Would like to understand the impact of reduced volunteer availability = of reduced external sponsorship to the different options. - Document should discuss the impact to IRTF and IAB as well. Also, the = role of IAB as an advisor to ISOC is not discussed. Here IETF (IAB) supports ISOC. - The fund-raising responsibilities, accounting of costs, re-envisioned = funding model have a clear monetary motive, transparency has a community motive, but = other changes have less clearly motivated background. - The oversight discussion lacks the recognition of possible conflict of = interest for oversight persons (IAOC) and volunteer workers in IASA overlap. EDITORIAL We've received a number of editorial comments: - Adding "... and to preserve IASA's negotiating position" under Section = 3.3. - Section 4 goal on clarifying roles should start with oversight role. - Under Section 5.5., the Executive Director should be accountable to = the IAOC or Board (to make it match all three options). - In Section 3.1.2, under ISOC represention one could add that confusion = about when ISOC member/donor is actually supporting standards development vs. other = ISOC activities. (Also other editorial suggestions in the same Section). - Suggested wording changes in Section 3.3. - Better wording for the item around IETF Trust under 5.1.1. - The first bullet about ISOC's role in Section 5.1.3 seems = contradictory to the model. =20 From nobody Mon Nov 13 16:40:29 2017 Return-Path: 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 82713126CD6 for ; Mon, 13 Nov 2017 16:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 GAGEjadJJsqH for ; Mon, 13 Nov 2017 16:40:20 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0C35129465 for ; Mon, 13 Nov 2017 16:40:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 19D1ABE2E; Tue, 14 Nov 2017 00:40:18 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhMxmvac_0Eu; Tue, 14 Nov 2017 00:40:16 +0000 (GMT) Received: from [31.133.146.8] (dhcp-9208.meeting.ietf.org [31.133.146.8]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7E828BDF9; Tue, 14 Nov 2017 00:40:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1510620016; bh=MsS9E3D6++ctmMolLvA5dcrmqemphAJnkfMc84KEpSI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=YK7aD2l7SMsKaT0f40ICTouKPNd22AL54XRJ94V6HCihDpVHuJ+0RI/ZfSz14xTMU Nr27jQSK9J7oz13X/6POkHlZVxounnFGQrkNmRibR/Fo2G1qgsV+x1Dx41sgEdnlbm L1qJy7fqtctR5OiH13FNGkrVLYnbNXpiHOvAm/eU= To: "Livingood, Jason" , Jari Arkko , "iasa20@ietf.org" References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> <596586DD-785D-4B84-AD71-295664508037@cable.comcast.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 14 Nov 2017 00:40:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <596586DD-785D-4B84-AD71-295664508037@cable.comcast.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AvjARAjS8HB8cGifj4GldcGTh8PEGiohG" Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:40:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AvjARAjS8HB8cGifj4GldcGTh8PEGiohG Content-Type: multipart/mixed; boundary="Fw0pp4Cr44M9wTSoO6HwwvsG1UDteuT0O"; protected-headers="v1" From: Stephen Farrell To: "Livingood, Jason" , Jari Arkko , "iasa20@ietf.org" Message-ID: Subject: Re: [Iasa20] Thank you & we need your feedback References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> <596586DD-785D-4B84-AD71-295664508037@cable.comcast.com> In-Reply-To: <596586DD-785D-4B84-AD71-295664508037@cable.comcast.com> --Fw0pp4Cr44M9wTSoO6HwwvsG1UDteuT0O Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 14/11/17 00:24, Livingood, Jason wrote: > On 11/13/17, 7:02 PM, "iasa20 on behalf of Stephen Farrell" wrote: >=20 >> I don't deny that there are other > issues (fundraising) that might be better handled via the other > options but I've not been convinced by the list traffic that > fundraising or other issues better handled via the other options > would be fatally undermined in the IASA++ scenario.=20 >=20 > [JL] I noticed a number of the global sponsors at the last meeting and = on this list suggesting otherwise (that the current approach is problemat= ic).=20 >=20 I agree that this aspect is likely harder in the IASA++ scenario but I don't recall people saying that IASA++ was a showstopper for that. >> I think the subsidiary or independent organisation options will > not be achievable in the next year=20 >=20 > [JL] I agree with your sentiment that we must strike a balance =E2=80=93= we don=E2=80=99t want to spend years and years on this but at the same t= ime it=E2=80=99d be unfortunate to be back discussing a new approach in j= ust a few years time. So I guess the key is to get to the right administr= ative model that will last the IETF another 10 years or much longer, but = not take up years of time doing so. >=20 Agree. =09 >> I'm not keen on the IETF incorporating and like our current > situation where anyone can contribute and nobody needs to be a > member.=20 >=20 > [JL] The administrative options the DT has been considering would not c= hange the participation model. Indeed =E2=80=93 preserving it is listed a= s one of the key goals. >=20 I agree the document sets that as a goal and believe that the DT and people commenting don't want to go there. But over an ~10-year timeframe I still think IASA++ reduces that particular risk so for me that remains a reason to prefer IASA++. Cheers, S. >=20 >=20 > =20 >=20 >=20 > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 >=20 --Fw0pp4Cr44M9wTSoO6HwwvsG1UDteuT0O-- --AvjARAjS8HB8cGifj4GldcGTh8PEGiohG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaCjtrAAoJEC88hzaAX42i0WEH/2EkmwWMq9SGV9id/NC8NRrT n2MvK4EgV+069s0Dq9wjE32CKB6mOOdfc9nIBkCD/LwH2weMchxKp3emsKMmYEdM f2hCLCyPCfkAE8k+DqSq+MUvNKQmpY7eWbREXJ+bB5dFaYkbGgWA3sX1AGr7n+9K ioaLVXVB8bQdIsa59b6mccbd4RFv5zToOHS6tf059RxB6CnA0PpQ4RF8AQY/M+km 5xT9y3sXdwfNhobaowecLTQ6r66xLLMk1x+zs0koDBUfCqmAs3hN33ERG3YNAEIE YN0sTdHVvEgV0ae/NmRq9l/XwjG5k65F9HAg5uIXR5uWlX3D5Cadm7f+RQ9u+hM= =CgZZ -----END PGP SIGNATURE----- --AvjARAjS8HB8cGifj4GldcGTh8PEGiohG-- From nobody Mon Nov 13 16:41:18 2017 Return-Path: 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 7CF55126CD8 for ; Mon, 13 Nov 2017 16:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Yw5dXbaj; dkim=pass (1024-bit key) header.d=yitter.info header.b=fKjFFs/T 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 IVEGbUuH0IKu for ; Mon, 13 Nov 2017 16:41:15 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9C7126CD6 for ; Mon, 13 Nov 2017 16:41:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 5F34EBF56B for ; Tue, 14 Nov 2017 00:40:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510620044; bh=MTHscOpUCbcs0kvVrHWJSlBXL1hirGH8uNltezlI2kQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Yw5dXbajbmLDUqexEtDqusyCREYyxGZmnaN3L7n7QMc0Xa/EilwfKMpxRuWDkDM90 LvIDW5cYO0AytQ0JrScB+Ci9iXet1zB6J3DtPrTjwg/+gSijeOJ9e8fMlYbeLBbWMX RjW0zQXU86Qs+c1R4/q0wxAUu62CmhT8dNUYQ0JY= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHqMFNhTqNLF for ; Tue, 14 Nov 2017 00:40:43 +0000 (UTC) Date: Mon, 13 Nov 2017 19:40:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510620043; bh=MTHscOpUCbcs0kvVrHWJSlBXL1hirGH8uNltezlI2kQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=fKjFFs/TkKUA0k9phD2sLHiBdhfBxdNJDZE2fSYuVtEAmTDHRObGmiANZFGnEaJP8 lxkmk1aVaMSImGeT4WL6FbBsbuoPxGlzFsw8q8Jdrp2pcp+dF4tq+e7sT+7fRhphiK Lmtta0NMbmLVrSabeUpUNpBi/hZ+19Sk1ZlkqD3M= From: Andrew Sullivan To: iasa20@ietf.org Message-ID: <20171114004040.b3seqnlb3fcyi7vv@mx4.yitter.info> References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> <8f6a64d0-38f5-efbb-7d20-1e7372d17e61@cs.tcd.ie> <12f446e4-2969-6924-fd70-2afde56b8db6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12f446e4-2969-6924-fd70-2afde56b8db6@gmail.com> Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:41:16 -0000 Hi, On Tue, Nov 14, 2017 at 01:20:22PM +1300, Brian E Carpenter wrote: > The alternative problems are probably best described as > "ICANNitis", in other words an organization that develops > a dynamic of its own that its stakeholders don't like. I had assumed that we were already facing that issue, or we wouldn't be tackling IASA20 at all. That is, if we thought the administrative arrangements were already working perfectly smoothly, there would be no pressure to make any adjustments at all. I don't think the rough bits are just accidents: we have been operating this mechanism, and if it isn't working quite as we like then that must be because it has some inbuilt issues. The question therefore is what mechanisms one can build now to make reforms that make appropriate corrections such that (1) we are not subject to pressures that restore the current irritants and (2) we do not create new pressure points that create a different set of problems. I think one can legitimately disagree about the right way to go about that, but I don't think one can consistently claim that one of the options does not entail making any structural corrections and still claim this work is worth doing. If there are no structural changes to make then this is all just a really expensive way to collect information for the existing IASA and maybe the nomcom. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Nov 13 16:42:56 2017 Return-Path: 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 E8BA3126CD8 for ; Mon, 13 Nov 2017 16:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=ZEhDnW/7; dkim=pass (1024-bit key) header.d=yitter.info header.b=NobugWeU 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 V4wDxBOrlCVr for ; Mon, 13 Nov 2017 16:42:54 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F91126CD6 for ; Mon, 13 Nov 2017 16:42:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 638ACBF56B for ; Tue, 14 Nov 2017 00:42:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510620173; bh=p38dlWc7xE65ec1nLBlQJ3Wf4YeVB6jdJrYeiSZLuss=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ZEhDnW/7xEmqZu6+T4Avmmbt5EuEeRq9npdc2qyNlTbBkYKxJuhSxcOG22bvlUbS3 vDXO7h87SOWdvb7N6+QxUrkgvBL+63zH/TNWkwmfx0aiOZqvs/6aPZ0X3S7eexVsih gL3OrSPZ14IAfv4ig2qcmleR7Lgm4GXuhRKqK4BU= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpDZtszFhnzq for ; Tue, 14 Nov 2017 00:42:52 +0000 (UTC) Date: Mon, 13 Nov 2017 19:42:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510620172; bh=p38dlWc7xE65ec1nLBlQJ3Wf4YeVB6jdJrYeiSZLuss=; h=Date:From:To:Subject:References:In-Reply-To:From; b=NobugWeUq2xmvQpEKNQi58rwJDT8+DSOH0FBOa7fLyjbf0Z/VTGMoHs/ldll1E2zl c4HA0/6J+US9K2HHFvUZgXLRkfTP8DGh5FJ9Gc4//GoPucYkt9GTZk0MSoTeBU+5rv P4muWoAUXTctiG1PqD9JI+7NyCGdEIn2act2LnYo= From: Andrew Sullivan To: iasa20@ietf.org Message-ID: <20171114004249.7zj5hsedvafyulqw@mx4.yitter.info> References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> <596586DD-785D-4B84-AD71-295664508037@cable.comcast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:42:55 -0000 On Tue, Nov 14, 2017 at 12:40:11AM +0000, Stephen Farrell wrote: > > > > [JL] I noticed a number of the global sponsors at the last meeting and on this list suggesting otherwise (that the current approach is problematic). > > > > I agree that this aspect is likely harder in the IASA++ scenario > but I don't recall people saying that IASA++ was a showstopper for > that. I actually don't see how it is not; see my recent arguments about this. In case it was not clear in those previous postings, let me make it clear now: I do not think that a completely legally-subsumed part of ISOC can ever escape those problems. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Nov 13 16:59:51 2017 Return-Path: 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 19EEB126D73 for ; Mon, 13 Nov 2017 16:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 skbMeztlGkKj for ; Mon, 13 Nov 2017 16:59:48 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CE05126C26 for ; Mon, 13 Nov 2017 16:59:48 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id k191so6654819ywe.1 for ; Mon, 13 Nov 2017 16:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KBUyGg2qkfZmg0YP0oxhy8y2E2K4AOqrp2tPlkd/ujA=; b=UOqLeg5hUd/rGVASaD+8qwE59hHUaXxQn9Rt6+NYrwXFvuuInssQ9ZysNzIzpZkMeP AKFrtWPzSfr7Hl4UC5hXRFtLsDn6fuNaseuoMu771Xd0R0xM8A0qq3zFu4kRonkoa3nL ziah8xWQJx36WspBghDSZYfGtydrlqdKFHaycsH0ZpQvT2Hpnx25bkU2kwk8fw9giqBS W1aIQ/LWEligzz55s8/DCX4XVjME+m54iOqhwYHzAlEJCFmY2nMwlJEj2wEQCW+Iig8e uWUvY57g6EyUIPdp77EgFvW3dGOB7vB0xHiRonEgs4s69LoLIUbYO4pwa18Z4vyU+cIH 1sYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KBUyGg2qkfZmg0YP0oxhy8y2E2K4AOqrp2tPlkd/ujA=; b=mD7XRShbzyfbA1fVjOeM6z45V83imXWFUEJH2ld5xFn3zvKHCE6EGbK3LW2aZeujdO /izs7YjeX3R8DCI2AxnG0ZN4beYq0oY9ABjSGOld+iFJE9qm7ZEjckffBoofqgER+i0B dnIEI3SxlIo0G6YFF7JGuq4j4bZxFkueCQD0OIYrT1njgTVs8flVe1qLwzKHO68kUO8o ZgVbIxhqRR9uDJbCtHc/9zhP9MrPHxBzrvF8YC12A+niFKWawA+/6+3g0HoUqGA6hRli jElMnYavYP9NwbfS6oUSVU6Cps3FtQIIWVW/7H9nWs7SFth6o8VbhvgeQzczV3tFXR9B Zm5A== X-Gm-Message-State: AJaThX7AKRFpUHiIzhxJlAFuJSaSuxBXLaGtCqK8TWUw3NuXyHXx4Wln eEGL7qNmotbZ0TX2flddefyD2fyfldYg1KyszCpddZqW X-Google-Smtp-Source: AGs4zMZUW8fjU1LydLGQrLuWVW76HIt+Sr745BfM2LV9fd6X4pyR3ozJGTFvADzzkzpWPwHjFufD//FD0FbAQlHRdB4= X-Received: by 10.37.119.65 with SMTP id s62mr6766493ybc.339.1510621187231; Mon, 13 Nov 2017 16:59:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Mon, 13 Nov 2017 16:59:06 -0800 (PST) In-Reply-To: References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> <8f6a64d0-38f5-efbb-7d20-1e7372d17e61@cs.tcd.ie> From: Eric Rescorla Date: Tue, 14 Nov 2017 00:59:06 +0000 Message-ID: To: Stephen Farrell Cc: iasa20@ietf.org, Jari Arkko Content-Type: multipart/alternative; boundary="001a114ba4444167a8055de6e705" Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 00:59:50 -0000 --001a114ba4444167a8055de6e705 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 14, 2017 at 12:23 AM, Stephen Farrell wrote: > > > On 14/11/17 00:14, Eric Rescorla wrote: > > On Tue, Nov 14, 2017 at 12:10 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie > >> wrote: > > > >> > >> > >> On 14/11/17 00:04, Eric Rescorla wrote: > >>> OK, well, given that you don't actually provide any reason to believe > >>> that this will happen other than that you're anxious about it, I'm not > >>> really sure there's not much to usefully say here. > >> > >> Sorry, I thought it was fairly obvious: > >> > >> It seems to me to be in the nature of organisations to end > >> up more, and not less, bureaucratic. I think a more bureaucratic > >> organisation that could have members is more likely to end up > >> requiring people to be members. Either of an ISOC subsidiary > >> or independent organisation could impose membership as a > >> requirement. IASA++ means that's less likely to happen. > >> > > > > It's not at all clear to me that this is the case, given that ISOC > *already* > > has members [0] and it would therefore be trivial to require IETF > > participants > > to be ISOC members. > > I don't think that'd be at all trivial. The community would, I think, > be quite likely to strongly resist such an attempt. (I would anyway, > and I don't think I'd be alone:-). Changing our processes to ignore > such community input/resistance would require changing a bunch of > BCPs which is never trivial. > And these are exactly the obstacles that would exist in either of the other two models, except you would *also* need to create a membership structure first. -Ekr > > > > I think describing that as "anxiety" is trivialising what > >> seems like a real risk. > >> > > > > "seems" is doing a lot of work here. It may seem like a real risk to you > > but it doesn't seem like a real risk to me, and your text above doesn't > do > > much to persuade me. > > Sure, I'm not saying that mine is a killer argument. I'm also not > saying anything is inevitable, and it's fine that we evaluate the > risk differently as there can't be any certainties here. But, my > evaluation of that risk remains one of the reasons I personally > prefer IASA++ as of now. > > S. > > > > > -Ekr > > > > [0] https://www.isoc.org/membership/rules.shtml > > > > > >> S. > >> > >> > >> > > > > > > > > _______________________________________________ > > iasa20 mailing list > > iasa20@ietf.org > > https://www.ietf.org/mailman/listinfo/iasa20 > > > > --001a114ba4444167a8055de6e705 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 14, 2017 at 12:23 AM, Stephen Farrell <= ;stephen.far= rell@cs.tcd.ie> wrote:


On 14/11/17 00:14, Eric Rescorla wrote:
> On Tue, Nov 14, 2017 at 12:10 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie
>> wrote:
>
>>
>>
>> On 14/11/17 00:04, Eric Rescorla wrote:
>>> OK, well, given that you don't actually provide any reason= to believe
>>> that this will happen other than that you're anxious about= it, I'm not
>>> really sure there's not much to usefully say here.
>>
>> Sorry, I thought it was fairly obvious:
>>
>> It seems to me to be in the nature of organisations to end
>> up more, and not less, bureaucratic. I think a more bureaucratic >> organisation that could have members is more likely to end up
>> requiring people to be members. Either of an ISOC subsidiary
>> or independent organisation could impose membership as a
>> requirement. IASA++ means that's less likely to happen.
>>
>
> It's not at all clear to me that this is the case, given that ISOC= *already*
> has members [0] and it would therefore be trivial to require IETF
> participants
> to be ISOC members.

I don't think that'd be at all trivial. The community would,= I think,
be quite likely to strongly resist such an attempt. (I would anyway,
and I don't think I'd be alone:-). Changing our processes to ignore=
such community input/resistance would require changing a bunch of
BCPs which is never trivial.

And these = are exactly the obstacles that would exist in either of the other
two models, except you would *also* need to create a membership
= structure first.

-Ekr
=C2=A0
>
> I think describing that as "anxiety" is trivialising what >> seems like a real risk.
>>
>
> "seems" is doing a lot of work here. It may seem like a real= risk to you
> but it doesn't seem like a real risk to me, and your text above do= esn't do
> much to persuade me.

Sure, I'm not saying that mine is a killer argument. I'm als= o not
saying anything is inevitable, and it's fine that we evaluate the
risk differently as there can't be any certainties here. But, my
evaluation of that risk remains one of the reasons I personally
prefer IASA++ as of now.

S.

>
> -Ekr
>
> [0] https://www.isoc.org/membership/rules.shtml=
>
>
>> S.
>>
>>
>>
>
>
>
> _______________________= ________________________
> iasa20 mailing list
> iasa20@ietf.org
> https://www.ietf.org/mailman/listinfo/iasa20
>


--001a114ba4444167a8055de6e705-- From nobody Mon Nov 13 17:31:02 2017 Return-Path: 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 D1CED127010 for ; Mon, 13 Nov 2017 17:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0c6bNokwwpEv for ; Mon, 13 Nov 2017 17:30:59 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5351E1205F0 for ; Mon, 13 Nov 2017 17:30:59 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id y9so16112234wrb.2 for ; Mon, 13 Nov 2017 17:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=x/vrSi/Ww+lgDNjLaKS3FAHCZXQK3SQLipf8jJKwpRs=; b=kUaQ6OjLQ8KLP6ynNEoByJ1Eqs4/bVUKQ++eLuO5e9g3e0cheoJpWRycFZr1nbXuua Q6cUbt6zj2YlWlb6wra1g+zwlSt3SpidAjNRJSmRXg6w7/aStcjC6lJ/u1mjs3vvECeF GJ5nlUNx1l1Px1PIMjGkYGqP2Uj/ylsHP1Lt3dWN7gPyfY/1OKZas4WqvWnwBQFQqH2E mA0wnEr8ti0nfVaQkoUZDgmtV2sKCKnjTssNkAlSUTd5m/MDDGZvKueUDqEaKzDnV2n8 PA9Gq932pOedZd17+s8TxJn2IRLKCIM5x+4887gFTUDO3NL11HtQIQaXXCFV34PCwjKu 37jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=x/vrSi/Ww+lgDNjLaKS3FAHCZXQK3SQLipf8jJKwpRs=; b=q/7t7ZghrBCkW+3FmLhsfkjlfMtlgmDldqraUFGlbWt68sjoabUmd2T0qEe/ZCJa4z KQnDFBFCMEpUch4XouCBsYjiKYKW8zleCRu8X6Pd0w2RRXl/pVghB2nu4pzpFPU+wiIe 2izDtHIbrUvY4WlEMvAKi37m7Aq8zOodv5/pXVwEKzp2iVpiFuyf9gKGXYjPAx/LOgyD aU/T+1cOp9k0DccS1Z+Rn8cn/qA5xF1xjq7zJqA/HelqyvW6i1Pd4uZlGakWCoJDvIwp rt3aQ3ZQQoAtFYK3h9K2HfLWzVfouiUqPr79F+EtcVaU8Aq/UOuWiqBd9DSPO3J0Sc7y K3fA== X-Gm-Message-State: AJaThX7C+gwZvBvrAbuuwip1A136AUxiOmPXaeewpdul/5U9ZBdBjGv6 FjNCDWxp1GEQxgViISYaEoY= X-Google-Smtp-Source: AGs4zMaXuKvub57Kj7jn1Q1xsdCz4uYtcCyMEdkGn5vKcMWXgpdMb0vZP5gKtB67YOFEeHi98SpVAw== X-Received: by 10.223.184.205 with SMTP id c13mr7631806wrg.268.1510623057938; Mon, 13 Nov 2017 17:30:57 -0800 (PST) Received: from dhcp-810e.meeting.ietf.org (dhcp-810e.meeting.ietf.org. [31.133.129.14]) by smtp.gmail.com with ESMTPSA id c17sm19773343wrg.26.2017.11.13.17.30.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 17:30:56 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4F9CD3DC-4EC5-4B2D-B56A-84E2274B5490"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 14 Nov 2017 09:30:50 +0800 In-Reply-To: Cc: Bob Hinden , Stephen Farrell , iasa20@ietf.org, Jari Arkko To: Eric Rescorla References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 01:31:01 -0000 --Apple-Mail=_4F9CD3DC-4EC5-4B2D-B56A-84E2274B5490 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ekr, > On Nov 14, 2017, at 8:04 AM, Eric Rescorla wrote: >=20 >=20 > - I'm not keen on the IETF incorporating and like our current > situation where anyone can contribute and nobody needs to be a > member. I accept that some forms of ISOC subsidiary or independent > organisation could preserve that >=20 > Nothing we have proposed involves either (a) the IETF incorporating > or (b) requiring people to be members. >=20 I am pretty sure if we want to have our own bank account some sort of = incorporating will be required. Bob --Apple-Mail=_4F9CD3DC-4EC5-4B2D-B56A-84E2274B5490 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloKR0oACgkQrut0EXfn u6jlrgf/en/pAgZxXjYlwFGgCjbmDaPHaWgbX7KazZI74L2IVpsDsIDLHfJTgYqO SnNaEFnQ44UMRN+Emgbd4RG3/TZRFWDcKFMPKC7jf4zb3T5Bg9i+AObUp6JDluTR M2ChCkhroKtrFg76Up9VUZGKyyUH00HjPPJ2f4TpMgGUES51IJ93i4jt1yBbYxPA X6u2T5r0d4TBQPzrmDkZenJRgwogE4rKBa3PIZ3KfWPaVJgEvroKeacJ1sMiHLJj MqKUwSSR+1ASuwudJ6josiHVS4OnDuNz3AG3Yqpz+xetocwzGV+juZc01VrFZTNi wljCqJ7++gZkYVTxsWVTebGha+3vzg== =VQRW -----END PGP SIGNATURE----- --Apple-Mail=_4F9CD3DC-4EC5-4B2D-B56A-84E2274B5490-- From nobody Mon Nov 13 17:35:56 2017 Return-Path: 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 D998A127010 for ; Mon, 13 Nov 2017 17:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 qIVFSFJ2GnvS for ; Mon, 13 Nov 2017 17:35:54 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B61D1205F0 for ; Mon, 13 Nov 2017 17:35:54 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id p44so11616410qtj.6 for ; Mon, 13 Nov 2017 17:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g7sLVPhHMKE7pkzjJyW4eEuWSxGRGLcIfYK0D5AjAi0=; b=NcRWp/9BvffmUYvc+Ugv1B2E/o/7Ugz5D2IMlXr3GISBlvd+ZvAPVZ27T8w9wiCeBF WTKTchcjymeHpsLj8WAJPQIzFSxz5fv44R4czsP8b2wYjYNCTMSKJnwaE3Bul5CMA1mu fNGKqCPFBGF7dsx/9OACzDmEOXyqwHuu6TLMTEwgHY60nupIGtboec4KBv7kak9ilKWP nzG4OQcz7qf9egoBdFx6+KxHitswZ7udmZMfP1ZL+Sasi8TvvNuOgue7etA0eLG4rCyS f5af6vNcD9o0UOZc61Ir+LYdzoS5VLKthy3Jw+tPyalxo5tSeuMhSR3G7NAAcYcTjCOc YDDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g7sLVPhHMKE7pkzjJyW4eEuWSxGRGLcIfYK0D5AjAi0=; b=P4/6gjCDwpHpwLUfLrYl7x5zEkA/bs6IH7hlBG/9T/c5DFoic9Uy4I8Je9UfqKZh0q aL6KYAuAG4oKTsLLs85fGk8oLBGudVf48u+Cym1tzi1hAJyY/18+wMvaVh01yvs49F70 HzM8Jt/jc5AWxUWXVMjWnP7/kLA+jSrMc8pnAiR6eE6m7FOJav3zyFy3qN1J7i9ftPdR rdwTrOIfn43r4XG78AeAXuU88AktzpDcd6LEZSF54cWIw/xbTYauewwrbbNeYm5RNhdp A7audRchn+c7sA2QRsJu4E5umSSm3FlvlPrL2DwVAXaab0e62wbPQ07p0jdbMBdYHnxP eeCg== X-Gm-Message-State: AJaThX6V4I9q5FiUuuOezqdFjF5qJZIHmoIF8oM+F3ICXcPk+L92hC3c vGFi3zpsqJrezDknUFarUjyTF/XUr/ouJ/yGOmPyXw== X-Google-Smtp-Source: AGs4zMYkSUChyxWRhIM4F7BMMoXerkaS/ZNc5xY76fzOHrZAOkgfQR4i9Sw/gu8lNjbw7CGAowWof5TxuyXViV9L9Gs= X-Received: by 10.37.22.8 with SMTP id 8mr6982898ybw.353.1510623353662; Mon, 13 Nov 2017 17:35:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Mon, 13 Nov 2017 17:35:12 -0800 (PST) In-Reply-To: References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> From: Eric Rescorla Date: Tue, 14 Nov 2017 01:35:12 +0000 Message-ID: To: Bob Hinden Cc: Stephen Farrell , iasa20@ietf.org, Jari Arkko Content-Type: multipart/alternative; boundary="001a114167186286e6055de76869" Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 01:35:56 -0000 --001a114167186286e6055de76869 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 14, 2017 at 1:30 AM, Bob Hinden wrote: > Ekr, > > > On Nov 14, 2017, at 8:04 AM, Eric Rescorla wrote: > > > > > > - I'm not keen on the IETF incorporating and like our current > > situation where anyone can contribute and nobody needs to be a > > member. I accept that some forms of ISOC subsidiary or independent > > organisation could preserve that > > > > Nothing we have proposed involves either (a) the IETF incorporating > > or (b) requiring people to be members. > > > > I am pretty sure if we want to have our own bank account some sort of > incorporating will be required. > The proposal is not that the IETF incorporate but that we create a new organization which is incorporated to support our work. I think that's an important difference. -Ekr > > Bob > > > > > --001a114167186286e6055de76869 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 14, 2017 at 1:30 AM, Bob Hinden <bob.hinden@gmail.com> wrote:
Ekr,

> On Nov 14, 2017, at 8:04 AM, Eric Rescorla <
ekr@rtfm.com> wrote:
>
>
> - I'm not keen on the IETF incorporating and like our current
> situation where anyone can contribute and nobody needs to be a
> member. I accept that some forms of ISOC subsidiary or independent
> organisation could preserve that
>
> Nothing we have proposed involves either (a) the IETF incorporating > or (b) requiring people to be members.
>

I am pretty sure if we want to have our own bank account some sort o= f incorporating will be required.

The p= roposal is not that the IETF incorporate but that we create a new organizat= ion which is incorporated to support our work. I think that's an import= ant difference.

-Ekr
=C2=A0

Bob





--001a114167186286e6055de76869-- From nobody Mon Nov 13 17:40:05 2017 Return-Path: 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 8DF4C126E7A for ; Mon, 13 Nov 2017 17:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=foAbL6gq; dkim=pass (1024-bit key) header.d=yitter.info header.b=Uub1zwRX 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 71FjKCULf3YI for ; Mon, 13 Nov 2017 17:40:03 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B7F1205F0 for ; Mon, 13 Nov 2017 17:40:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id BB8AFBF56B for ; Tue, 14 Nov 2017 01:39:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510623572; bh=3fPpQT7cW8Bk/0LU5XtKMhmhE7qxcPpKfyaAdL1FzD4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=foAbL6gqVXJPzYxthy/5CiD88dyUnj0zOUhXwOAYfDSAl1gCbMUB1McLB8qQSK3oY jr82A4dO5iNyXdS9MVP8m9Ksaz9YOTP8OzQnU5ccu71vVmu7G7t10hz278pQAb3Q33 izR6mzEs2F5ol7Je9TsAn38NhVOWjtl4yOh10haM= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY3pTMkjUlnj for ; Tue, 14 Nov 2017 01:39:31 +0000 (UTC) Date: Mon, 13 Nov 2017 20:39:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510623571; bh=3fPpQT7cW8Bk/0LU5XtKMhmhE7qxcPpKfyaAdL1FzD4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Uub1zwRXsOfadAWFGy8G811km/P6mFyiED7IPifgCJtMpzxF3ZdE8H4WY4E3dLp0R pzvW7erNckLLqR2Cfd1B/i2u4qBUm5WW8r5412R+dZPyc8MrvQ0U5ASBGhiCxF4Wls YvYv2Lni3cBqXIaIBspcUVg+uzGnuW7H6G0s6FZY= From: Andrew Sullivan To: iasa20@ietf.org Message-ID: <20171114013928.hln2ebhpwv4yua5p@mx4.yitter.info> References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 01:40:04 -0000 On Tue, Nov 14, 2017 at 01:35:12AM +0000, Eric Rescorla wrote: > The proposal is not that the IETF incorporate but that we create a new > organization which is incorporated to support our work. I think that's an > important difference. That's the model I have: an organisation that stands in the same relationship to the IETF as ISOC does today, but without the additional interests that ISOC has, thereby providing a structural separation from those other interests of ISOC. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Nov 13 17:41:00 2017 Return-Path: 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 7AF5212954E for ; Mon, 13 Nov 2017 17:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 cauPC402uZnK for ; Mon, 13 Nov 2017 17:40:51 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 D1B6F1294E0 for ; Mon, 13 Nov 2017 17:40:50 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAE1bFnY032392; Tue, 14 Nov 2017 01:40:43 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=GQe4m10dZPrP+ZIP/yXYQu/nAFI9k89uA0QzTNXSL60=; b=g8PsZhtOxZA1T9oJWl26LptzEv4r2AzfqSHmUhXNcQwQ5E2hZtFYq8nxl9JMgGmzDszh bXOGGX/ZwA9CRXrRJlBqzgGTnr5+49dRLEUWwOArl45wW8YD18GPkT5aiHnFZhVUiYeE e+dS1eR2LKtoFSLc+kounzYl0GL9vOlna8VUg8L29ySiUk05EOs+MDfkmeIIYr9FGXWs PQl6w0LJwIzOZ6Pif8qhIXrnR89BiIIlcxMFLjmxDhudlAvYKTmGy1uJguYKuiYuMiVK jDBTC0hoICyzSxkbihGz7z1Y4zaivUPANabmTDpcF+/yhDdfGMA0QzS1Psg+yqQzrw1i kw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2e7p3y83ns-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 Nov 2017 01:40:43 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vAE1ZpBW008086; Mon, 13 Nov 2017 20:40:42 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2e7p3yr53u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 13 Nov 2017 20:40:42 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 13 Nov 2017 20:40:41 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 13 Nov 2017 20:40:41 -0500 From: "Salz, Rich" To: Eric Rescorla , Bob Hinden CC: "iasa20@ietf.org" , Jari Arkko , Stephen Farrell Thread-Topic: [Iasa20] Thank you & we need your feedback Thread-Index: AQHTXOjtuM9MDfGud0yYFyUECA9is6MTbScA Date: Tue, 14 Nov 2017 01:40:41 +0000 Message-ID: <051F5F4D-B997-4869-BC73-7CE1C5852886@akamai.com> References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.147.46] Content-Type: multipart/alternative; boundary="_000_051F5F4DB9974869BC737CE1C5852886akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711140019 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711140020 Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 01:40:52 -0000 --_000_051F5F4DB9974869BC737CE1C5852886akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBwcmV0dHkgc3VyZSBpZiB3ZSB3YW50IHRvIGhhdmUgb3VyIG93biBiYW5rIGFjY291bnQg c29tZSBzb3J0IG9mIGluY29ycG9yYXRpbmcgd2lsbCBiZSByZXF1aXJlZC4NCg0KSW4gdGhlIFVT LCB5ZXMuICBCdXQgdGhlcmUgYXJlIG90aGVyIHZlbnVlcyAoSSBrbm93IG9mIEJlbGdpdW0pIHdo aWNoIGFsbG93IHVuaW5jb3Jwb3JhdGVkIG5vbi1wcm9maXQgb3JncyB0byBwcmV0dHkgZWFzaWx5 IGhhdmUgYSBiYW5rIGFjY291bnQuDQoNCkkgYW0gbm90IGFkdm9jYXRpbmcgd2UgaG9zdCBvdXJz ZWx2ZXMgb3V0c2lkZSB0aGUgVVMsIGp1c3QgbWVudGlvbmluZyBpdC4NCg== --_000_051F5F4DB9974869BC737CE1C5852886akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBhbSBwcmV0dHkgc3VyZSBpZiB3ZSB3YW50IHRvIGhhdmUgb3VyIG93 biBiYW5rIGFjY291bnQgc29tZSBzb3J0IG9mIGluY29ycG9yYXRpbmcgd2lsbCBiZSByZXF1aXJl ZC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoZSBVUywgeWVzLiZuYnNwOyBC dXQgdGhlcmUgYXJlIG90aGVyIHZlbnVlcyAoSSBrbm93IG9mIEJlbGdpdW0pIHdoaWNoIGFsbG93 IHVuaW5jb3Jwb3JhdGVkIG5vbi1wcm9maXQgb3JncyB0byBwcmV0dHkgZWFzaWx5IGhhdmUgYSBi YW5rIGFjY291bnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IGFkdm9jYXRpbmcg d2UgaG9zdCBvdXJzZWx2ZXMgb3V0c2lkZSB0aGUgVVMsIGp1c3QgbWVudGlvbmluZyBpdC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_051F5F4DB9974869BC737CE1C5852886akamaicom_-- From nobody Mon Nov 13 17:46:02 2017 Return-Path: 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 884C2129463 for ; Mon, 13 Nov 2017 17:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 TAuLeIMwbHp8 for ; Mon, 13 Nov 2017 17:45:59 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A46C1270A3 for ; Mon, 13 Nov 2017 17:45:56 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id s11so8666972pgc.5 for ; Mon, 13 Nov 2017 17:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sWVRw1yzMea7tlSL8+lbFfG4A5GULGDSO1qlptf0E/0=; b=ZW8IjFxSi1FV1sNygFEGbXw0XkIvAukxvWwvAeVw4D0HhpF7qDktOG4UIXSsesk8h9 rZBpXVwQSKC8avNlTV2XmDAyepk1T7W5E+u+3CEwqP6u0a+w0x2z2hqLDbpnpIbY1IX2 lVrx5HfC/vitl3Sy15LWbHEUfFpvQObevBkITh+SAuC6a6T1nQfc1Oiwk3Lz/E3wTeBB FpAw50w9XirSMwZ+ihPso3lkY2CMehPaZaL6Fl6AmSLEBjjp9R+ukrbHa2HoO1SbnPNZ dbRDb2QG/phbxp3i3KFr3uUWmdMIR7TOGVlMCvnN2KfMUwcQGrKw4whW9i9wbEbkItBQ c5BA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=sWVRw1yzMea7tlSL8+lbFfG4A5GULGDSO1qlptf0E/0=; b=FTd8l/M3aYOk23X/rbMfF88fBpmPmhOXFDNB+3raZBfx7qNV7b+Wwkc2szEgRG6xfu R+OmKz3SwCGMrxhswhSjAPkxm7cZIQNyvnaHOY6Wge6rU7uiX6+10w4ojItMr/ASPRlt JxA7emN1UIqfQJkKi4V33cSETo9W91rNWLho4q0NgJiwDwxaeOJegxkjR40AlO2T+AxP h8NW9dpz7DYEh1JTGudBIrTPDr2o2VNI/ek0RNEvgTwJLFjlaOthsLxpiAexFG4eVPsz BI9O8wpKkzzAO5WKV/vO3WrWldxs9RJ+s7yUfiHhjER+vr8RXPVsQ2QLvKd8qysQOprU 5TEw== X-Gm-Message-State: AJaThX7KOB34DJXpSvry8x0hkkQJsB+goIlQgQcUbRg+BZ7sKAkLMvZF D+iWbYw6IQyknuim3DzQQ2adkQEO X-Google-Smtp-Source: AGs4zMb9U+ayG7KgQVYRiu6XZ/E7fSwc9Qvbt1QZVSGZeQ+8iQM3p5JYpoaZB6AUeS1Adr+8hqcu+w== X-Received: by 10.99.135.199 with SMTP id i190mr10267919pge.356.1510623955797; Mon, 13 Nov 2017 17:45:55 -0800 (PST) Received: from ?IPv6:2001:67c:370:1998:28cc:dc4c:9703:6781? ([2001:67c:370:1998:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 15sm29777331pfm.158.2017.11.13.17.45.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 17:45:54 -0800 (PST) To: Andrew Sullivan , iasa20@ietf.org References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> <8f6a64d0-38f5-efbb-7d20-1e7372d17e61@cs.tcd.ie> <12f446e4-2969-6924-fd70-2afde56b8db6@gmail.com> <20171114004040.b3seqnlb3fcyi7vv@mx4.yitter.info> From: Brian E Carpenter Organization: University of Auckland Message-ID: <9742afd8-634a-875d-4880-456c7a3dc4bc@gmail.com> Date: Tue, 14 Nov 2017 14:45:53 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171114004040.b3seqnlb3fcyi7vv@mx4.yitter.info> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 01:46:00 -0000 On 14/11/2017 13:40, Andrew Sullivan wrote: > Hi, > > On Tue, Nov 14, 2017 at 01:20:22PM +1300, Brian E Carpenter wrote: >> The alternative problems are probably best described as >> "ICANNitis", in other words an organization that develops >> a dynamic of its own that its stakeholders don't like. > > I had assumed that we were already facing that issue, or we wouldn't > be tackling IASA20 at all. That is, if we thought the administrative > arrangements were already working perfectly smoothly, there would be > no pressure to make any adjustments at all. 100% agreement with that. > I don't think the rough > bits are just accidents: we have been operating this mechanism, and if > it isn't working quite as we like then that must be because it has > some inbuilt issues. No, that's a non sequitur. Either it has some inbuilt issues, or we're not operating the mechanism correctly. Or more probably, both of the above apply. > > The question therefore is what mechanisms one can build now to make > reforms that make appropriate corrections such that (1) we are not > subject to pressures that restore the current irritants and (2) we do > not create new pressure points that create a different set of > problems. And (3) we do not drift away from operating the mechanism correctly in future. > I think one can legitimately disagree about the right way to go about > that, but I don't think one can consistently claim that one of the > options does not entail making any structural corrections and still > claim this work is worth doing. If there are no structural changes to > make then this is all just a really expensive way to collect > information for the existing IASA and maybe the nomcom. Right, but to the extent that the corrections needed are due to us not operating the mechanism properly today, the changes need not be "constitutional" in nature. Regards, Brian From nobody Mon Nov 13 17:54:03 2017 Return-Path: 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 10D4112954B for ; Mon, 13 Nov 2017 17:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 D534K_egTJMg for ; Mon, 13 Nov 2017 17:54:00 -0800 (PST) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495DB1270A3 for ; Mon, 13 Nov 2017 17:54:00 -0800 (PST) Received: by mail-wr0-x22d.google.com with SMTP id j15so16102966wre.8 for ; Mon, 13 Nov 2017 17:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=r9TdUBzQcX7TbWVgDUTaVofc+rVd720uw4ccpHN9zmw=; b=Ch36zIuVzzVQaKtCRTOYJWzDvodhhJkpf++QfATv4sRNuZ9FpEZ1+nlokUo4Vy002m cMjZYxV/wkSL4+KRuqvIztB9HstOEZMXLXy/iejXcoIPb4NHv/zUxYI7+V3rPkPnoSk2 lZL/lRyxTUHM+uz2FK9MvlXvHuaCRg3TDQYKWm+Kh9T8C5zrsNQmoFzPnu6NCH6uTfkN gSfBavLdVSfywfUWf+M4lBbT/F81OTlIPDofaePaooZvS9E5lInkS9aEvWJIlaFTU88c S+e7r/gnqC72euuLYIT/RpZKXt/Fwur9l2HwPDOFXlUqqrBqDw0NJeOGqFbpKTwcWgXi y71g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=r9TdUBzQcX7TbWVgDUTaVofc+rVd720uw4ccpHN9zmw=; b=QWD8STJCiuvmm4gw4lB0fD1wfiASxNubZQQn81ka0r5VCJrsXTEZWylOweJI+Pw3Wc nX8c53BONFNxwi/5oAD6vOayvsBqUMTo91h4c6i4Qj430NDoGYjN5YCwnOajdp8iet1b WfaByKwha417ygklVN4bwfCfsIqNb/UDUbZr8Pbw/qiPG7eeShWI3iZssDx1znK79FMg tGCnMThUQv4ERkZCuAhwIADR88jVGT+iUI6+Yy6nT7ckeyUILaGsIa+xhuzNre1rpKV4 B5/GRG54WcJhGpBFJ/arWvZq5F/vRMkspRsaYG4JH0cbQ6ijXMFGHQir8AERCPrCIlrU LztQ== X-Gm-Message-State: AJaThX5VfEiIUJ+Cp5J+TTo3S73TlDcVFPBX9Mtdqwwm3P6Yo2HiLHB1 J9gDZLE/H4iYGB7LkY5NIp0= X-Google-Smtp-Source: AGs4zMaVa2QrJA9FUGlRbepP8glPyc78DJSF41oeK4OvLgYHNe+jNldgoeMznceuahBqVcbEbjtFqg== X-Received: by 10.223.195.138 with SMTP id p10mr7917494wrf.88.1510624438817; Mon, 13 Nov 2017 17:53:58 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:34d1:62d2:25c8:9c2c? ([2001:67c:370:128:34d1:62d2:25c8:9c2c]) by smtp.gmail.com with ESMTPSA id h66sm7811364wmd.11.2017.11.13.17.53.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 17:53:56 -0800 (PST) From: Bob Hinden Message-Id: <49333458-8AE5-4BBA-9728-9356C9308075@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F037F040-4742-49D1-8F86-2C7FBBD8845A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 14 Nov 2017 09:53:51 +0800 In-Reply-To: Cc: Bob Hinden , Stephen Farrell , iasa20@ietf.org, Jari Arkko To: Eric Rescorla References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 01:54:02 -0000 --Apple-Mail=_F037F040-4742-49D1-8F86-2C7FBBD8845A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ekr, > On Nov 14, 2017, at 9:35 AM, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, Nov 14, 2017 at 1:30 AM, Bob Hinden = wrote: > Ekr, >=20 > > On Nov 14, 2017, at 8:04 AM, Eric Rescorla wrote: > > > > > > - I'm not keen on the IETF incorporating and like our current > > situation where anyone can contribute and nobody needs to be a > > member. I accept that some forms of ISOC subsidiary or independent > > organisation could preserve that > > > > Nothing we have proposed involves either (a) the IETF incorporating > > or (b) requiring people to be members. > > >=20 > I am pretty sure if we want to have our own bank account some sort of = incorporating will be required. >=20 > The proposal is not that the IETF incorporate but that we create a new = organization which is incorporated to support our work. I think that's = an important difference. It is, and apparently getting lost in the discussion. I think this = needs to be clarified. At least for me, some high level org charts of = the different choices would be helpful. Bob >=20 > -Ekr >=20 >=20 > Bob >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_F037F040-4742-49D1-8F86-2C7FBBD8845A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloKTK8ACgkQrut0EXfn u6hynggAuV2Y5xDUqDBzDUsNCpOk1FBaueWcTGLhdonS635GEeXywVrPNC0o/n1i G9fEPV4e/Z0sJKzaXcZBrN5XeH0fVNwAfkGvq5jznTi6cSWJy8qc4i9iAz5Z0mzR /XSEj5d8IPTYdcmXnDkjfQBH1J7goxV8/xTQTuCwhCNOXgDm0p4Hb/kKlQFgvVdg trwCOIZhN6bH+j59S/mZ0ClT8FOTk1VC4d3EmuFiEZEjud1ei6OW8HLk9KPr62Oe e8hIwRmJTOoTuzmcqEV2GjoH95syYIV3qu0Y198z9a7SU0OoHtaTVoYuJh4QEzrn g/70TAKMc6JBNmaUhPsPfja7KMcNrg== =wukg -----END PGP SIGNATURE----- --Apple-Mail=_F037F040-4742-49D1-8F86-2C7FBBD8845A-- From nobody Mon Nov 13 17:58:15 2017 Return-Path: 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 0562A129B66 for ; Mon, 13 Nov 2017 17:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 5vgt9wS-yunf for ; Mon, 13 Nov 2017 17:58:09 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C630129B56 for ; Mon, 13 Nov 2017 17:57:57 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id n61so22136183qte.10 for ; Mon, 13 Nov 2017 17:57:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3qqk+3ZS/MX7JEmQLojh5SUBlE3nuLzwOGj4LCyIIAs=; b=CGYSXK+gCSh7feHQs1jLis2yD4xc0BrBG3wisM9PSCYhndB3aImbXy2YBRgIXu8b5p CkXWkKhzw8/DPu1tYtSgDw1EkeUbgKfphmQNOdDCanw+sJsNMOZHrbLaLJJlxUF9ewRV X/iprAccaQW3S/1vAuPXGJEMFZZPh5Iwh+rFSQeyLmr8hiRRX11cf9byIQn6IzgWVuMo EOhil87Mxf4OQQtWYOLkSE7174h/9ou1BeBp5OjE+ktT3eSzfthPQEtfAKYii8LIFCj3 u1/Ab00BR2isv0eLM+tph0RULqs1hnV54Px9oq84is1F29Tv0Jmsb4wgLC2aplvA66xu KTog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3qqk+3ZS/MX7JEmQLojh5SUBlE3nuLzwOGj4LCyIIAs=; b=NI4NwDbf6qkOum8m5QcpVMFk+aR8weC4OscTusff1a75kMWU9kYsehEXoA1JmsLpJs a03EVyNoOz9PzJMnJGTzHxrXBI4I0PO/1PLaWX6RquNszhknu9vDsugYMb8Czonrp1Zt uAGMCOAHmu1Km7DNrN30nnd+xCiVJVYF7yaKhcQL7Um4LkdtA8WbKris3wqBeydjBy34 VaiIqEDt+d61jGhrMvYAPZl73STJIfapHG6jyBStT59rXe1Eeuy7XOSECmn5h1QO8RXD ST0DapamLy2iJtULTjm3lKof1cAj0eNN6qy76O8u9J1EFrIw6JB3Tl/OxM6sUm4O6IWp ok8w== X-Gm-Message-State: AJaThX5Lwl9gtYJ7clC8PW2tJGUNkY91QEftm/1laindtLs3FmU3MAf/ cbwVmf9hY3Nc82wtgl/Z14ZRC7phehlBRmFaMBx7VCl5 X-Google-Smtp-Source: AGs4zMa+bw3PnayD9OYPcxDn0vPcVGmQ/eCMk1BmW/UbiZYe2/VS6PdiNVa2cDMu26xS9g/+7BN9wGKUD2BWPeJzGew= X-Received: by 10.37.216.7 with SMTP id p7mr1501205ybg.397.1510624676137; Mon, 13 Nov 2017 17:57:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Mon, 13 Nov 2017 17:57:15 -0800 (PST) In-Reply-To: <49333458-8AE5-4BBA-9728-9356C9308075@gmail.com> References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> <49333458-8AE5-4BBA-9728-9356C9308075@gmail.com> From: Eric Rescorla Date: Tue, 14 Nov 2017 01:57:15 +0000 Message-ID: To: Bob Hinden Cc: Stephen Farrell , iasa20@ietf.org, Jari Arkko Content-Type: multipart/alternative; boundary="94eb2c05e80a35e806055de7b7d6" Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 01:58:12 -0000 --94eb2c05e80a35e806055de7b7d6 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 14, 2017 at 1:53 AM, Bob Hinden wrote: > Ekr, > > > On Nov 14, 2017, at 9:35 AM, Eric Rescorla wrote: > > > > > > > > On Tue, Nov 14, 2017 at 1:30 AM, Bob Hinden > wrote: > > Ekr, > > > > > On Nov 14, 2017, at 8:04 AM, Eric Rescorla wrote: > > > > > > > > > - I'm not keen on the IETF incorporating and like our current > > > situation where anyone can contribute and nobody needs to be a > > > member. I accept that some forms of ISOC subsidiary or independent > > > organisation could preserve that > > > > > > Nothing we have proposed involves either (a) the IETF incorporating > > > or (b) requiring people to be members. > > > > > > > I am pretty sure if we want to have our own bank account some sort of > incorporating will be required. > > > > The proposal is not that the IETF incorporate but that we create a new > organization which is incorporated to support our work. I think that's an > important difference. > > It is, and apparently getting lost in the discussion. I think this needs > to be clarified. At least for me, some high level org charts of the > different choices would be helpful. > Thanks. I think we could manage to produce some ASCII art for this, -Ekr Bob > > > > > > > -Ekr > > > > > > Bob > > > > > > > > > > > > --94eb2c05e80a35e806055de7b7d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 14, 2017 at 1:53 AM, Bob Hinden <bob.hinden@gmail.com> wrote:
Ekr,

> On Nov 14, 2017, at 9:35 AM, Eric Rescorla <
ekr@rtfm.com> wrote:
>
>
>
> On Tue, Nov 14, 2017 at 1:30 AM, Bob Hinden <bob.hinden@gmail.com> wrote:
> Ekr,
>
> > On Nov 14, 2017, at 8:04 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >
> > - I'm not keen on the IETF incorporating and like our current=
> > situation where anyone can contribute and nobody needs to be a > > member. I accept that some forms of ISOC subsidiary or independen= t
> > organisation could preserve that
> >
> > Nothing we have proposed involves either (a) the IETF incorporati= ng
> > or (b) requiring people to be members.
> >
>
> I am pretty sure if we want to have our own bank account some sort of = incorporating will be required.
>
> The proposal is not that the IETF incorporate but that we create a new= organization which is incorporated to support our work. I think that's= an important difference.

It is, and apparently getting lost in the discussion.=C2=A0 I think = this needs to be clarified.=C2=A0 At least for me, some high level org char= ts of the different choices would be helpful.

Thanks. I think we could manage to produce some ASCII art for this,<= /div>

-Ekr

Bob



>
> -Ekr
>
>
> Bob
>
>
>
>
>


--94eb2c05e80a35e806055de7b7d6-- From nobody Mon Nov 13 18:00:59 2017 Return-Path: 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 D76371200C5 for ; Mon, 13 Nov 2017 18:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 8k-HpVasPq-r for ; Mon, 13 Nov 2017 18:00:57 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B7A12954B for ; Mon, 13 Nov 2017 18:00:54 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 90AE0880E2 for ; Mon, 13 Nov 2017 18:00:54 -0800 (PST) Received: from clemson.local (unknown [IPv6:2601:154:c003:b30:6825:8dfa:683c:483a]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 59D6F3280AE4 for ; Mon, 13 Nov 2017 18:00:54 -0800 (PST) To: iasa20@ietf.org References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> <49333458-8AE5-4BBA-9728-9356C9308075@gmail.com> From: Brian Haberman Message-ID: <6b88bfe2-ed7d-bcc3-f732-c93c562194d1@innovationslab.net> Date: Mon, 13 Nov 2017 21:00:53 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jvW3DifAba65loLSIPvM2xv5JIdnf6uAW" Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 02:00:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jvW3DifAba65loLSIPvM2xv5JIdnf6uAW Content-Type: multipart/mixed; boundary="Pl9NSV9uExoeuOddcq1ER8BHkSafgT72U"; protected-headers="v1" From: Brian Haberman To: iasa20@ietf.org Message-ID: <6b88bfe2-ed7d-bcc3-f732-c93c562194d1@innovationslab.net> Subject: Re: [Iasa20] Thank you & we need your feedback References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> <49333458-8AE5-4BBA-9728-9356C9308075@gmail.com> In-Reply-To: --Pl9NSV9uExoeuOddcq1ER8BHkSafgT72U Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/13/17 8:57 PM, Eric Rescorla wrote: >>> The proposal is not that the IETF incorporate but that we create a ne= w >> organization which is incorporated to support our work. I think that's= an >> important difference. >> >> It is, and apparently getting lost in the discussion. I think this ne= eds >> to be clarified. At least for me, some high level org charts of the >> different choices would be helpful. >> >=20 > Thanks. I think we could manage to produce some ASCII art for this, Or real art these days... Brian --Pl9NSV9uExoeuOddcq1ER8BHkSafgT72U-- --jvW3DifAba65loLSIPvM2xv5JIdnf6uAW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaCk5VAAoJEGjWPJxT0YthLUwQAIakJ7YKXb7NXntgEO7HH+Y4 MumhDT32c3VMGA1a0ho8Q4hHPs+9w2Neuzk0Yi4NnD/lWlmpB/12yDYzpYwfAfEh jKwvyf8OAmJvMorsVu13cp5AAU/7juD3y79AkmYkztST2s3spu4/6D5jxG3aartS 7QnpNDl6lNvTiLPpYbdaJdjY7bzMDTpa3ZfcpM9ElRRmJGFmpQIDG+xb//2nIecI JSpkRePQYJM4xJdWp9VYgq7k2UK2+tnNhDYvJ4APpz32Ibe3zjVpx6DUoWBrypaw 6JJF0/QGY/Bp0mYvhjuqdAe1EhRgssj8poXSoWr0hW0cpIp6RFdlA9XHnDdSzmf6 7FOWy6rNJfQRlBmT0xAL7rMkDtAUlEbwvZ8i31Go6doDPzuEJRa3NtQ7iU+eA/MI ALEUm+Ww1nT1uglUzyuk1R4r2IYgC5y2X123KmNWzF5FryPAH2KpBr1JOf3KC2TC Hw6aIdbHPVc5/4vOa99qxnR2NP/YYY47JfmVyeK1WsdkFHR5tVui3o/PkcyGpj6+ fMGauoI9Vhp2ZnERWj6EqAmZ/weRXBaAUb9jR8oqd5dK9sobmdP3adsaXKnKTikZ PFwTtghld1jewFC8w0sc22q5yhNpMF/e/JqdRnl2VAk9BgLUcvhCEJzdWNCnpd+T ms3C8qnEKZ9NYQ9bGg+U =3H9B -----END PGP SIGNATURE----- --jvW3DifAba65loLSIPvM2xv5JIdnf6uAW-- From nobody Mon Nov 13 18:02:56 2017 Return-Path: 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 953DC1200C5 for ; Mon, 13 Nov 2017 18:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 SPjs7jUOOBi4 for ; Mon, 13 Nov 2017 18:02:50 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FCB129AEA for ; Mon, 13 Nov 2017 18:02:50 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id v186so9840706wma.2 for ; Mon, 13 Nov 2017 18:02:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j2GJLMXTrci3bnfato9MyWM2c2MrNxugxZEeTB0of2I=; b=rY2HOS0wRjZFaeyicltRNXt3dO1RMqmy2f++GmSXrWEvPybhIuN+2034HAXScjBwsA Y78Pl32T9HWphrqYaERhz+lTCTJFNRoDu7776FyalZDAeGVj8mKxYE0V3hIfFUAsP7gK BcOKUHBbhViTF2SovDDbE6nr1hjW/YanjrgzolzJ7liDB1X5ux1GZlZdR/z/K4r9QhF2 Yoaq2qea9q3Zxg7Ggi/FMmJCxBoAkQ0N41fInA9kn7TB3fDzwxdz5Wr9fbst4osDslVb uqUDQST62M9yS/4wjKSlqzWDdczBIBhZAYP1kWlzNSuiiqg6LW+l+QDJMn2dsRovdcGC ka4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=j2GJLMXTrci3bnfato9MyWM2c2MrNxugxZEeTB0of2I=; b=rsnV9RHhVRuMeIWQ4XS2eoXh78hvgNDg0ZOqweWCnWMXo2ekR4nhrckuFRxWk8nlpl oQkyqkRu3pEWzrLxPIpslJKuvqhdmn0kBm9q8oW83fXdZ1xPzlIB7IU3cTVx2CUBD69p Cp5gu3n4gj5fJ+j7tte4OlqD8Se6d2QfdsNy8SnQAX/YNOkgb5u0A5fmc4t4DcpCA6kG z/+TlF81KWZg0eDuo6kcmJnlYnhblk2PnNGSR0vnT7h7zj4ScmRk7bisMUIDuTeIxk7J tSuCxyno0XuFGIWTTfp9Nw+APon5tDICDMCQSXge4mDm282BlMkGcx8VKXpW/FjpE/gW rIqQ== X-Gm-Message-State: AJaThX5jG95rYBkXU+abgNqp+sYhcZHVlI25BruyK/IRHHdnWBzOIGW9 IChr084VwzVOnq9kRKM2+b504rSjr4ocwO+lsBbi/A== X-Google-Smtp-Source: AGs4zMZJBtRyIdIX2n4nIliPnQJ5u0EFHseSTpVJflnwXy/TdOKuFFut/pwMkgZvtaemdt3aE/9M0A0yabWAh83XwX8= X-Received: by 10.28.156.67 with SMTP id f64mr7263289wme.42.1510624968574; Mon, 13 Nov 2017 18:02:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Mon, 13 Nov 2017 18:02:47 -0800 (PST) In-Reply-To: <49333458-8AE5-4BBA-9728-9356C9308075@gmail.com> References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> <49333458-8AE5-4BBA-9728-9356C9308075@gmail.com> From: Richard Barnes Date: Tue, 14 Nov 2017 10:02:47 +0800 Message-ID: To: Bob Hinden Cc: Eric Rescorla , Jari Arkko , iasa20@ietf.org, Stephen Farrell Content-Type: multipart/alternative; boundary="001a114b3208a41ee4055de7c857" Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 02:02:52 -0000 --001a114b3208a41ee4055de7c857 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 14, 2017 at 9:53 AM, Bob Hinden wrote: > Ekr, > > > On Nov 14, 2017, at 9:35 AM, Eric Rescorla wrote: > > > > > > > > On Tue, Nov 14, 2017 at 1:30 AM, Bob Hinden > wrote: > > Ekr, > > > > > On Nov 14, 2017, at 8:04 AM, Eric Rescorla wrote: > > > > > > > > > - I'm not keen on the IETF incorporating and like our current > > > situation where anyone can contribute and nobody needs to be a > > > member. I accept that some forms of ISOC subsidiary or independent > > > organisation could preserve that > > > > > > Nothing we have proposed involves either (a) the IETF incorporating > > > or (b) requiring people to be members. > > > > > > > I am pretty sure if we want to have our own bank account some sort of > incorporating will be required. > > > > The proposal is not that the IETF incorporate but that we create a new > organization which is incorporated to support our work. I think that's an > important difference. > > It is, and apparently getting lost in the discussion. I think this needs > to be clarified. At least for me, some high level org charts of the > different choices would be helpful. > Here's a rough representation of my understanding: https://ipv.sx/tmp/IASA-org-charts.pdf > > Bob > > > > > > > -Ekr > > > > > > Bob > > > > > > > > > > > > > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 > > --001a114b3208a41ee4055de7c857 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 14, 2017 at 9:53 AM, Bob Hinden <bob.hinden@gmail.com> wrote:
E= kr,

> On Nov 14, 2017, at 9:35 AM, Eric Rescorla <
ekr@rtfm.com> wrote:
>
>
>
> On Tue, Nov 14, 2017 at 1:30 AM, Bob Hinden <bob.hinden@gmail.com> wrote:
> Ekr,
>
> > On Nov 14, 2017, at 8:04 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >
> > - I'm not keen on the IETF incorporating and like our current=
> > situation where anyone can contribute and nobody needs to be a > > member. I accept that some forms of ISOC subsidiary or independen= t
> > organisation could preserve that
> >
> > Nothing we have proposed involves either (a) the IETF incorporati= ng
> > or (b) requiring people to be members.
> >
>
> I am pretty sure if we want to have our own bank account some sort of = incorporating will be required.
>
> The proposal is not that the IETF incorporate but that we create a new= organization which is incorporated to support our work. I think that's= an important difference.

It is, and apparently getting lost in the discussion.=C2=A0 I think = this needs to be clarified.=C2=A0 At least for me, some high level org char= ts of the different choices would be helpful.

Here's a rough representation of my understanding:

=C2=A0

Bob



>
> -Ekr
>
>
> Bob
>
>
>
>
>


_______________________________________________
iasa20 mailing list
iasa20@ietf.org
https://www.ietf.org/mailman/listinfo/iasa20

--001a114b3208a41ee4055de7c857-- From nobody Mon Nov 13 18:22:36 2017 Return-Path: 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 49CA612954B for ; Mon, 13 Nov 2017 18:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 9SlGjSAx5uVb for ; Mon, 13 Nov 2017 18:22:33 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 397DC1270B4 for ; Mon, 13 Nov 2017 18:22:33 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0EEF820008 for ; Mon, 13 Nov 2017 21:24:09 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 845F880CFA for ; Mon, 13 Nov 2017 21:22:32 -0500 (EST) From: Michael Richardson To: "iasa20\@ietf.org" In-Reply-To: <051F5F4D-B997-4869-BC73-7CE1C5852886@akamai.com> References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> <051F5F4D-B997-4869-BC73-7CE1C5852886@akamai.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 02:22:34 -0000 --=-=-= Content-Type: text/plain Salz, Rich wrote: > I am pretty sure if we want to have our own bank account some sort of > incorporating will be required. define "own"... > In the US, yes. But there are other venues (I know of Belgium) which > allow unincorporated non-profit orgs to pretty easily have a bank > account. I believe that as part of of the transition from ISOC doing the bookkeeping, to AMSL doing the bookkeeping, that a new bank account was opened. I don't know if it's "our own bank account", as I'm sure that there is ISOC Board authorization to change the list of signers, yet I'm pretty sure you could inspect the statements if you wanted to. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloKU2gACgkQgItw+93Q 3WWz4wf9GR96NusjIcRJDr2kAle6rttuQyiQSqjY5f0gCk5MTPhADkpnvMScOEwg dRPIx+H5LmAbcZaU75FC2dAEjnu09ng+XBF16m2O0GCJHEyO16nZ+9nXPDhtg6oE 4HufctC1qMjhOoQKruOiJOgb3BwlR/uol+pAVvKVmz2D0ZTJh/LP3ofyP5cqsqdc U2LDxhJLCydbxcFqumGz5j6o9B29vjPPB+EDSM8r1ncO5kV8oRYUULPqYPIZi2ru S5LmV1W8X/KXM+tZ4Fe6HVGYpPc6MHMP+xGKLZiG8jsO/UlpQIscjBRaG/rDEyhg G3InH7Crog27nNSCD7tMhMAS0YKtaw== =cWD/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 13 19:57:53 2017 Return-Path: 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 72B9F12704A for ; Mon, 13 Nov 2017 19:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 j5lZAdhJWE45 for ; Mon, 13 Nov 2017 19:57:49 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E530F1242EA for ; Mon, 13 Nov 2017 19:57:48 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id u10so8212956otc.12 for ; Mon, 13 Nov 2017 19:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=hpnNh2DJhN5nkYpjs1XaCbMM1qk3oZXuYaAyOyQnjiU=; b=W4QRKo5tKl/wCs0M+e6dlLVeavKMgYR3A/I/G75u6HQ4QIBmedTF3wu0HSB23I4Hlt FAbqNgZJUmYEfrycMOQmDf2R74lU1p90dqogaCvFHoMcIzEQFhjR+I7L9G8h3rszE6vs Pgpqc4uVo/4tzTeepZfhAFAh6ox7BfBTb+284GRDhFZ6mERnVZuNotvDTluOC/GnNjFO qoie5xraBHWjXf+WZL64f8iQKIVNuYEEWjS/V4hV0oVYTyaJVlHLAz7EYYnGk0Vu4q8w m55majLAVM3O5ettAUhTbzIA2lygUrYsmF+hr7y5dRgSZNrpVGOoJv4pURNXnWghNrBK qVAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hpnNh2DJhN5nkYpjs1XaCbMM1qk3oZXuYaAyOyQnjiU=; b=W7H/rKlO/NR8r7MeneraQZntl+AC56mWkv5ky68qvuxTts/ZDeNKk4kRQ+SYpVjHW6 tY/Sf3JC4XX0P8cmsjxtXXI0DQqL0wkd3KNpcS6C1tu+N8JXiZjlI2n4LwRn2mmBZhwg Ye9+YvA4ChALi+ySYuBEmTx5qIZkh7mCjuKGQzbjHTPGxWMl/7xeqhB+Bj6h0CFaCFRe zBbFkMDnYCMicmTiDft3GifogfI3b5dbuzBliB9VvQ451sAHQELC5uWjaOC88momPyCx oGi98wkPbsinDnD2mGryI0MTATg44sAhfDgFOH3tiXN+eShM6mCxvnNQVYFLQYByPNnp vEjw== X-Gm-Message-State: AJaThX4qOme7+8YdyImreWdALsK0ROVNbgsvneNHUgYPsvmieHMUL4s6 R9CxgsZaNSqFvPiC5x79MKYuZPcbkuB2f6OwME8OQi2E X-Google-Smtp-Source: AGs4zMZUH1uZMwsooXVo18Et+Ca3qIzuJsxMZkFzO07oOHXGd6LWMbPzOlHYqWq1Wq+cop/3qxeuTqiKjIvG6eV5Rs4= X-Received: by 10.157.11.24 with SMTP id a24mr7581433ota.401.1510631867361; Mon, 13 Nov 2017 19:57:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Mon, 13 Nov 2017 19:57:46 -0800 (PST) From: Martin Thomson Date: Tue, 14 Nov 2017 11:57:46 +0800 Message-ID: To: iasa20@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Iasa20] Raw minutes X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 03:57:51 -0000 IASA 2.0 IETF 100 Chair: Jon Peterson Scribe: Martin Thomson Jabber Scribe: Rich Salz # Brian Haberman Presents dt report what administrative arrngement best supports the IETF going forward? outline of issues: clarity, resources, transparency, funding and operational model mismatch outline of goals Transition options IASA++ ISOC Subsidiary Independent Organization # Jari Arkko provides an update on the discussion thus far Feedback on a range of topics, starting with the three options, then ISOC relationship, financial matters, staffing, the role of the trust Suggested path: pick an option of the three presented, then work on the details # Leslie Daigle on the inter-organizational challenges John Levine: (long list of qualifications) please figure out what the administrative structure is going to be, a subsidiary can be very much independent of ISOC, but we will expect that ISOC will continue to fund the IETF - there are few sources of so much money with so few strings attached Leslie: we need need to draw the line between IASA++ and subsidiary John: we need enough structural separation so that Kathy doesn't have to continue signing all those contracts Tobias G: we have sponsorships for IETF and ISOC and those all go to ISOC, and there has been a lot of confusion, this is an important consideration, perhaps the top for me. We can handle all of these things. It might be difficult to address individual things, but we're not in crisis. The bulk of the items in total is why we are doing this. Jari: We have a working system, but we are asking if we can improve. Wendy S: W3C is also not a legal entity and are struggling in similar ways. Looking at these options, I see a lot of things that work as they are. There wasn't a lot about institutional momentum that comes with creating an independent organization. Prefers IASA+. Leslie: are you concerned that the org would gain a life of its own Wendy: yes, and not through malice, but as a result of its existence Jon: how do you see that being different with ISOC? Wendy: I see that as less pronounced with ISOC Jari: that is one of the consequences. I prefer having greater control, over reducing the layers. Ted: In response to John's "All of this will fall out into a legal structure". This could be structured around clear delineation of responsibilities for business units. Except the funding issue. Clarifying the business units doesn't help with the external funding sources. A structure that makes the branding enough different (something). The amount of funding and staff we need should not change significantly. We should be careful to avoid substituting staff energy for the technical contributions of the community would be bad. Brian Carpenter: It's all my fault. Assuming we make a new org - which took a year last time - this is going to take a long time. I suggest once the analysis is agreed, splitting into two problems. Things that the IAOC can fix in its current form and just have the IAOC fix them. And the rest. Then run the two operations in parallel. We have the opportunity to do some things soon to fix the problems. Leslie: It will be easier to do that with a sense of where the community wants to land. Andrew Sullivan: Agree. And disagree with Brian. I don't think that we agree on the fundamental problem. These costs are being paid right now, but they are externalized. We can't fundraise. ISOC pays for communications and other things. The bureaucracy exists, but someone else is in control of that. ISOC has thus far been benevolent and supportive, but the question is whether we want to be grown-ups and do this, or are we going to continue to be wards of ISOC. We need to make that decision. Leslie: In the last few years we have been attempting to capture ISOC expenses and taking responsibility about these things. Joe Abley: People have pointed out that the call from ISOC has been awkward in the past. That ambiguity is an older problem. It's good to know that it's considered important. Jari: if we have a clear organization, we're just moving money around, but if the organization is complicated you can pay costs. Ekr: Happy to hear that there is no more cold-calling. I was confused as a donor about why I was negotiating with ISOC about this. But I had another point. Staff capture. I am concerned about this. I don't see us avoiding this. ISOC employ technical staff. If the administrative org is chartered to be administrative, then that works. I have never had to argue with Alexa about TLS, but I have argued with ISOC people. Pete Resnick: Missed things: ISOC has an appeal process etc... Not hard to deal with, but add it to the list. The way that I sell my employer on the IETF is to have them become a member of ISOC. They think that membership is important. We still want to be able to say that an ISOC membership is a way to support the IETF. Q: Is ISOC decided? Does ISOC have an opinion? Gonzalo Camarillo: We made it clear that we support whatever happens here, we have allocated $1M for this process, but the decision is an IETF decision. I don't think that it would be a good idea for ISOC to express an opinion here. ISOC is committed to supporting the IETF no matter the outcome. Sean Turner: People are asking whether the ISOC is kicking the IETF out. Which is crazy. Personally, I think that it makes more sense to professionalize the organization. The IETF has grown up over the years and needs to continue to do that. It makes sense to have a little more control. I'm more in the middle of the spectrum from 1 to 3, more like a 2 (subsidiary). The confusion about identity on sponsorship still as well. Leslie: plug for her retrospective draft Jonne S: I was part of the first IAOC. The new doc is much more mature now. We need a change after 10 years. Things like this can be done as different business units. ISOC is tiny. ISOC can be made flexible enough to support the IETF. We can also manage a subsidiary. All are possible. Having a separate budget can be done within ISOC or not. The first and second I would support, but the third (full independence) opens a whole number of questions I don't think we want to handle. Such as jurisdiction. Too complex. The confusion issue with sponsors is more about execution. Tobias: ISOC is always helpful and generous. Am I a member of IETF or ISOC? ISOC has a different mission. That creates different motivations for sponsors of the two organizations. If I donate to ISOC, it all ends up in the ISOC budget. Gonzalo: As a global host. We can make this work, but it was problematic. Now it kind of works. But setting it up was difficult. We were already a member of ISOC, so it wasn't clear. ISOC has three separate budgets for its three initiatives. But only platinum members can earmark money for specific goals, we could fix that. Having more clarity would be helpful. Barry Leiba: Huawei understands how this is setup. We will continue to support the IETF either way. The structure isn't relevant to us. We got here because ISOC grew. If we create a structure, we need to ensure that we don't also grow. ???Cisco: As a host, I'm optimistic. There are three things clarity, consistency and channeling. We give money to ISOC for third world nations, we do a lot for hosting IETF and hackathons. We want to be able to channel money to particular goals so that we can understand how our investments are being spent. How we get the money and direct it is difficult. Richard Barnes: I want to push back on this business unit idea. It can have some effect, but it won't help ensure the IETF control over these administrative functions. As long as ISOC employs people, ultimate decision-making capability is not with the community. Glenn Deen: We are platinum members of ISOC, and that is distinct from the IETF as a global sponsor. There are two line items on my budget. Simplifying this has a lot of benefits from a funding perspective, particularly for new donors. Figure out the problems and your goal first. Alissa Cooper: It's great that Cisco and Ericsson have worked out the difference between ISOC and IETF. I have spent a shocking amount of time on sponsorship issues. And there is an additional barrier at the start of these conversations. In response to Joe (Abley), the changes and improvements came about because Leslie and Ray and I spent the time to find Joe so that he could help with that work. These were only baby steps. That work wasn't accounted for in the current administrative structure. Ted: In all of these options, we cease to be a ward of ISOC. Some of these are more of a partnership. In IASA++, this is two partners. In the subsidiary relationship, the same applies. There is a lot of talk of ISOC and IETF as two separate entities, and we haven't internalized the fact that they are the same entity. We should work with ISOC to find which of these options works best for THEM. It's clearer if we go to something like a subsidiary model. In any of these, we need to understand that it requires a reorganization of ISOC as part of this. Jonne: I think that I agree with Ted. It's how the IETF wants to adminster and how ISOC is involved. We will have to step up. There is a model where we can be more effective. Once we have that model, we can see how the legal structure best fits. Linux Foundation has a range of organizational structures with greater independence. How we organize is a minor point. Jon: Is there any condition that makes the line between IASA++ and subsidiary critical? Jonne: A legal entity or not makes little difference on these things. To be honest I don't care. Leslie: We have so far articulated the stresses and straings. Do people have allergic reactions to particular outcomes on this continuum? Brian Carpenter: The essential characteristic of the new model is oversight. We have got to up-level where we put our stakeholder effort. We need to oversee what is going on. We didn't implement that part of BCP 101. We need to get to that position where the oversight is being performed as oversight and the work is being performed as work and the two don't get mixed up as they seem to be. Jari: Some of the examples do point to some things being easier with a clearer organizational boundary. Lucy Lynch: The weakest parts of this proposal are the oversight and professionalization parts of this. Both of which aren't clearly understood. Fixing the overloading of the relationship around contracting and funding changes the culture. That can be distancing. The first two models can work. The third model presents more challenges. Andrew: I want to poke at the business model analogy, which is in part incorrect. A line of business approach doesn't have a way to address some of the legal problems. We don't have a legal relationship between the IAOC and the organization we would want it to be responsible to. Maybe there are scary parts of this, but the legal relationship is an important part of the consideration. Some of these are not possible unless you set up legal distinctions that we just don't have. Tobias: "ward" is a bad word. IETF/IAOC was generally in control when it comes to discussions. Bob Hinden: I have been a different chair at different times. The interface needs to be a lot clearer defined. There has been friction in recent times. On the spectrum, I don't see how we get to independent. We would be dependent on ISOC for funding anyway. We are probably looking for something between IASA++ and a subsidiary. Maybe "supporting organization" is a better word. When you have to file your own tax return, that's when there is a difference. It seems to me that if we want to become more independent, then leadership is going to spend even more time on funding. I don't think that you can have staff that have the same concerns as our leadership groups. I think that we should do as a little as possible. I don't know if that is IASA++ or a subsidiary. Barry: I largely agree with Bob. There are lots of oddities. Let's do whatever we need to do to fix these problems, but minimize the changes we make. I lean toward IASA++ and way away from complete separation. Jari: The question is how we organize so that we can operate most efficiently. The trade-off is the cost of a re-org vs. the long-term costs of living with inefficiencies. Gonzalo: ISOC's technical work gets a lot of credibility as the home of the IETF. Often that work is promotion of IETF activities. We need to be clear about the relationship. Some of the problems with the channeling of money are not going away as a result of the choices we make here. You aren't going to solve the problems with routing of money entirely. Leslie: From a visibility perspective, there are differences. Kathy: This relationship is healthy. The IETF is a partner. It's been a good experience. We won't lose that. 1. there is a governance issue that is a legal issue, ISOC has legal and fiduciary responsibility, I need to worry about these things as CEO; the way we are setup, ISOC is legally responsible for many things, but we have little control over some of these things. We have many policies. None of those policies don't apply to the IETF - I don't think- and there is a lack of clarity. There's a layer of ...stuff here that needs to be cleared up. You could do this and make it horrible, but you can guard against that. We should keep the culture and sort out the governance issues to remove the doubt about this stuff. Questions like signing authority are easy in a subsidiary. I know that I'm not supposed to have a point of view, but I would hate the independence option. Sean Turner: supporting organizations is what we are really talking about, and there are three types. We should consult with a lawyer if we go there. ekr: I've seen a lot of beauty contests. I expected a hum. I get the impression that we already agree to be somewhere in the general area of having some legal distinction, but still largely related. Suggest that we have a group go out and work with that remit and come back with a more detailed plan. Can we hum on that plan? Lucy: That is fine, it doesn't deal with the structure of the IAOC, cultural, staffing, overloading issues. It's only a piece of the problem. # Alissa Cooper on humming chicken-and-egg - there are some things that these choices make possible that others do not. Want some hums so that we can make progress. Intend to have a working group charter drafted based on the conclusions we come to here. 1. do you have enough information? strong for, some against - rough consensus for 2. IASA++ hums, subsidiary hums, independent none, none of the above some - loudest hum for subsidiary, some for IASA++, almost none for independent, some for none of the above Lucy: from the discussion, there is greater clarity, but that is only one component of IASA 2.0. We only have enough information on renegotiating the relationship, not on the entire piece. Pete: If we can pick IASA++ and have legal authority/autonomy, which I heard from Kathy is impossible in that model, ????? I we can't have lega independence AND IASA++ are people still happy with IASA++? Alissa: do we have to do some more work? Pete: maybe... scribe lost track here Leslie: A next step here is to understand the ISOC perspective better. We shouldn't rathole on the IASA++/subsidiary distinction. We need to explore more. See this as necessary but not sufficient, to Lucy's point. Alissa: Can people speak to process: that is, some small number of people going to ISOC and working out requirements and details of options Harald Alvestrand: Humming is great for taking options off the table and independence is clearly off the table. The question here is which lawyers you call for advice. We have a mandate for exploring more about subsidiary, but keeping IASA++ in mind in case that doesn't work. I'm happy to see that we have a way forward. Stephen Farrell: Agree with Lucy. There are bunch of things we should also be working on in parallel. I don't think that we need to sort this out before we work on those other things. Alissa: I disagree with Lucy. I think that these issues are all intimately related. And we might look at all these issues across the spectrum between the two options. Lucy: I would like to see all the things considered. Stephen: there is a whole set of problems on which you can still work on. Ted: We should not wait until we get a long way down any path before we charter. That helps us get community buy-in. I would write a charter as an ISOC supporting organization (maybe check with a lawyer on that). ekr: second what Harald said. We don't want to have another suite of options. I think that we heard a general direction and we should give people that direction to explore. Let us try to make a thing work, and keep the alternative in reserve. Sean: I think that we have a path forward. I can find a lawyer. That's easy. I think that we can do this in a reasonable time-frame. Jonne: We have a clearer path forward. I would want to charter a working group to work on the governance model. Out of that we can work out whether IASA++/SO is better. We could even ask the lawyers to propose a structure. I think that we should instead take the governance model to the lawyers to implement. Alissa: give us an example? Jonne: (gives an example) start from requirements Sean: giving money to lawyers ensures that it gets spent. We need to be clear. Lawyers will run tests to ensure that we meet the criteria for the different supporting organization types. Gonzalo: build momentum, use the charter to do that. We can expedite some of this. Harald: these two options are mutually exclusive, but we have to choose: we have a subsidiary or not. We can mangle things so that one looks more like the other. Please just choose. Portia: the legal question means that the subsidiary question is important Alissa: next steps are unclear. We will kick off some coordination with ISOC. We should get better clarity about the options. We aren't there regarding a focused charter just yet, but we might get one to kick around on the list. Jon: We should at least get through the options as Sean described. As a next step we can explore the options more as Sean says. From nobody Tue Nov 14 10:49:47 2017 Return-Path: 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 E9D5C127868 for ; Tue, 14 Nov 2017 10:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham 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 Vrq9cGY_AbAh for ; Tue, 14 Nov 2017 10:49:44 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316AD127B5A for ; Tue, 14 Nov 2017 10:49:44 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0CEAA20008 for ; Tue, 14 Nov 2017 13:51:22 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 22721829D1 for ; Tue, 14 Nov 2017 13:49:43 -0500 (EST) From: Michael Richardson To: iasa20@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Iasa20] Raw minutes X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 18:49:46 -0000 --=-=-= Content-Type: text/plain Thanks for the very detailed minutes. I had to be in another room to present, but since I was remote, thanks to the magic of meetecho, I listened to a lot of the session. It seems that a significant amount of the grief is that we don't have a bank account that accepts checques that say "IETF" on them. I'm sure that this is easily solvable without creating new legal entities. (In Ontario, Canada, I can pay $55 at the mall to register my "Operating As" name at a machine that is often mistaken for an ATM. I'm sure that such concepts exist elsewhere) My observation as a non-voting member of the IAOC finance sub-cmte is that IAOC was already moving in the direction of IASA++, even before we started this conversation. (probably due to the same initial spark) I've heard lots of comments about "friction", and it really seems like something that few want to actually be specific about. Since the "ward" analogy has come up, my impression is that we have been young teenagers who have lived care-free for some time, and now that we are 20-something, we want to stay out late and manage our own money. One option is to move out (and file our own tax return!). But my impression is that ISOC was created in great part so that the IETF wouldn't have to do that. That we essentially had the most of the ISOC board (all?) in the room for IASA20, and that it's open to anything at all suggests to me that this is not like the conflict between a ward and it's parent(s). To stay with the batman/robin example: this is not about Dick Grayson leaving Wayne Manor. Rather, this is about Superman and Batman realizing that somebody has to clean the Hall of Justice. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloLOsYACgkQgItw+93Q 3WUBNAf/URCIypV36oP/vqRUzRNJV0DSioUVRVmGhzV8EVFHAudyVO5YIHx818Ws URU8DdqedsMtyorV+AzTq5CoppWJRlc+5WDc2pVNQ6RmJPDOEdf0IMwoYDHPU+h6 SgK1rn3+K+qUQp4RvlyQ0yL03pcpKuzoP8RQ6cLUswU4FkNZ8yf5BLQr+IwEKkbp Xr/MkYE8myJ76mc/3r3r1fOpSDZeDrdw5r2D/nO9hDAofZFHrLL2wNI5oM8fHekH t/pZ2NYj/0ONPTEzGUzjqJM31VNBt4klm6W49Zx65StPfdVNrQaqdUhBs7DIgxf+ FFqyVgQPWb2udDZX3BuJ04A9ul0IFA== =WgKW -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 14 16:34:10 2017 Return-Path: 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 6DCF4126B71 for ; Tue, 14 Nov 2017 16:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 PQGqFWR6mg07 for ; Tue, 14 Nov 2017 16:34:07 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 79B811250B8 for ; Tue, 14 Nov 2017 16:34:07 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAF0W54Z002355; Wed, 15 Nov 2017 00:33:55 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=hNbXgeSh95gQ26BJ0QqVS6F9X57f76w2w0n6cYu+ciw=; b=ZKSRUhpsBZ42DFTxXK41pC5guSCHs9T4FoLetVK33EWbfxayhJUcZdhJn8x0XyV5STJx ROYm+M25bvAODj5UD9z0Sp0LncHIEVZY+BudF0Ods1nfhCyV96XPH1VaRxAllMIbwu+1 ZuStpa6UBP8Ae/UbX+oT6tfPAGoqjPWzmTFcDqW648b42shhXEklFsYk2xAepI+VtL71 +K22G4j3jmCpwc2pz1yGVyvrehpmcZ6f/v96dbkvsUeI8MJHi9QmtBXaA8V6WLxsNLnU +Xw8pD4TVMXVEFi7EYfpTrJq/Ft5rMCqLJkIu7J2ssqqQ/AiWAqcaKr7mEQ70pvvb+Zl MQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2e7p3yb4r4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Nov 2017 00:33:55 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vAF0Vcw8030054; Tue, 14 Nov 2017 19:33:53 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2e7p3wkdbt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 14 Nov 2017 19:33:53 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb3.msg.corp.akamai.com (172.27.123.58) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 14 Nov 2017 19:33:53 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 14 Nov 2017 19:33:52 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 14 Nov 2017 19:33:52 -0500 From: "Salz, Rich" To: Richard Barnes , Bob Hinden CC: Eric Rescorla , "iasa20@ietf.org" , "Jari Arkko" , Stephen Farrell Thread-Topic: [Iasa20] Thank you & we need your feedback Thread-Index: AQHTXOjtuM9MDfGud0yYFyUECA9is6MTcNaAgAACf4CAAXl9AA== Date: Wed, 15 Nov 2017 00:33:52 +0000 Message-ID: <00FF16DC-C46C-4C86-9AAD-91368FB87DCF@akamai.com> References: <56e00e66-cb24-ca2f-7ab5-cdad456f819b@cs.tcd.ie> <49333458-8AE5-4BBA-9728-9356C9308075@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.147.119] Content-Type: multipart/alternative; boundary="_000_00FF16DCC46C4C869AAD91368FB87DCFakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711150006 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711150006 Archived-At: Subject: Re: [Iasa20] Thank you & we need your feedback X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 00:34:09 -0000 --_000_00FF16DCC46C4C869AAD91368FB87DCFakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCiAgKiAgIEhlcmUncyBhIHJvdWdoIHJlcHJlc2VudGF0aW9uIG9mIG15IHVuZGVyc3RhbmRp bmc6DQoNCg0KICAqICAgaHR0cHM6Ly9pcHYuc3gvdG1wL0lBU0Etb3JnLWNoYXJ0cy5wZGY8aHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19pcHYuc3hf dG1wX0lBU0EtMkRvcmctMkRjaGFydHMucGRmJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBO NkxaZyZyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmbT13amZ3ZjRsb1A4cjBhemJtTXFzY0R4SE91 T3FJV3NxNTVvQV9mdjM3MTZrJnM9TFNDbjdrX3FzNWZYZ3lkNEpvTF9wQ0lMamNISFVQSmVLRGhO Y19Vd3ROdyZlPT4NCg0KDQpUaGF0IGlzIHZlcnkgbmljZSBhbmQgY2xlYXIuICBJdCB3b3VsZCBi ZSBnb29kIGlmIHRoZSBkcmFmdCBhdXRob3Igc2FpZCBpZiBpdOKAmXMgYWNjdXJhdGUgOikNCg== --_000_00FF16DCC46C4C869AAD91368FB87DCFakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <893588CF89308744B3D5B115FC1DEF8B@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLmdtYWlsLQ0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC07fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBE ZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6OTIwNjAzMjY4Ow0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo1NzE2Mzk0OTYgNjc2OTg2 OTkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1h dDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv g5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJ bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K dWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJn Y29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDowaW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkhlcmUncyBh IHJvdWdoIHJlcHJlc2VudGF0aW9uIG9mIG15IHVuZGVyc3RhbmRpbmc6PG86cD48L286cD48L2xp PjwvdWw+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19pcHYuc3hfdG1wX0lBU0EtMkRvcmctMkRjaGFydHMu cGRmJmFtcDtkPUR3TUZhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPTRMTTBH YlIwaDlGdng4NkZ0c0tJLXcmYW1wO209d2pmd2Y0bG9QOHIwYXpibU1xc2NEeEhPdU9xSVdzcTU1 b0FfZnYzNzE2ayZhbXA7cz1MU0NuN2tfcXM1ZlhneWQ0Sm9MX3BDSUxqY0hIVVBKZUtEaE5jX1V3 dE53JmFtcDtlPSI+aHR0cHM6Ly9pcHYuc3gvdG1wL0lBU0Etb3JnLWNoYXJ0cy5wZGY8L2E+PG86 cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0 IGlzIHZlcnkgbmljZSBhbmQgY2xlYXIuJm5ic3A7IEl0IHdvdWxkIGJlIGdvb2QgaWYgdGhlIGRy YWZ0IGF1dGhvciBzYWlkIGlmIGl04oCZcyBhY2N1cmF0ZSA6KTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_00FF16DCC46C4C869AAD91368FB87DCFakamaicom_-- From nobody Tue Nov 14 19:48:09 2017 Return-Path: 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 3FC131294D4 for ; Tue, 14 Nov 2017 19:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 eWf1RNtc5ZtQ for ; Tue, 14 Nov 2017 19:48:01 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0043.outbound.protection.outlook.com [104.47.34.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC0312878D for ; Tue, 14 Nov 2017 19:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IH9eOzseknpcDJL8fNdYBj5Mwh0ZMy1vxQKnpsrbShc=; b=PbS0zdnk1bXBcC/j/Nj8M39Y3XgVtvnkXKURhrVTyAiG322+7BUZW+6Xujg2Mi3yrlL7DFOi5LscP4lD6M+09zDWqnfLLlT4BJX2KPuKllX2tw5CDwbwvuiTkjvNVz4n2tlW7vLo2N8vWgM+jiQSxSzM4uAWIRzDm1QHJZBOPPU= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ford@isoc.org; Received: from [IPv6:2001:67c:370:128:51bb:8db5:25b1:f6c5] (2001:67c:370:128:51bb:8db5:25b1:f6c5) by BL2PR06MB2212.namprd06.prod.outlook.com (2a01:111:e400:c751::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Wed, 15 Nov 2017 03:47:54 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Matthew Ford In-Reply-To: <16708.1510685383@obiwan.sandelman.ca> Date: Wed, 15 Nov 2017 11:48:05 +0800 Cc: iasa20@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <095ABCC8-91EB-427F-91FD-96B49BF2CFC7@isoc.org> References: <16708.1510685383@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3445.4.7) X-Originating-IP: [2001:67c:370:128:51bb:8db5:25b1:f6c5] X-ClientProxiedBy: SG2PR0302CA0003.apcprd03.prod.outlook.com (2603:1096:3:2::13) To BL2PR06MB2212.namprd06.prod.outlook.com (2a01:111:e400:c751::26) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 23b52fee-6445-478c-f340-08d52bdba81a X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:BL2PR06MB2212; X-Microsoft-Exchange-Diagnostics: 1; BL2PR06MB2212; 3:ZK1VpiLMrM/LU1DszLWjt63h/T9iJkerNHR71uV/N19KiYteAoOCgOQkDatPqAsBL/0SUJ6mZHb717kYUp4kHZgOIRVerS8Bx4iFiRtwMeTri0KGDUJK8QFW4677DB4FghREdVyqK2J30KjelIMUb5r1lpM9S2ynbbqFt7S9aeHXHQwzp2WoQcnQsFmZ3XJDiBK0yJBS/r8Ak7IyBv9iD0axmc4T8hRP+2H5hugdoJlwlmyjAXqH0g9s0B0EY9Qf; 25:Oiclh5GUTkX1PYitJs1O/L9NjCllfqCBWTpGwOrxLD+J20qKFSJE5QpYub8uDU762yLf8wm4QIqGiQtwXzECfeGR92noaE8DHbaK0tLcG9rBB4a4n9DjbuTb5KX522+6eLbzTBBkeztyV1LvmNMvEjSK2k+/PZLkGHkTM1QHXwA1OoQ2MAj8IVW1nwzIEDR791uMcUNBV9zdFScanKpyRA16Ydtd69i4PKPFqSDyrJPGa5MQE5530mkfz+I2GcpiEjACb4l6sOX+7qhWBCXFsXpOxpV/DT5ZyzjXXBJU2N/I9TUA/E8DFU4mWHmb2ns+K30rEPZZeoKGzmnsmuaVOQ==; 31:v7bABp8Hf5qgDkfkqjDll9FGfGzC+dN0IxhvsHa9+djTuZglsYTz6bXByUqfRvhBDpc7oY3dCN6Ng92Ex2GKF/wD/zVGNg8XXN0ZhHOq45n7qV4GS+xJ1u4JNzENKIx0NiDuGrzgjLcFlfEdes0va8ZATLhTkHxm0r4W8IG5GRDq77324HEcqPvcfxvkxj5brXoCc6Pr00d9sMJ5r1JOWSkJqHjLBAKNHMxk+6AxZb4= X-MS-TrafficTypeDiagnostic: BL2PR06MB2212: X-Microsoft-Exchange-Diagnostics: 1; BL2PR06MB2212; 20:rkLMnLP0D4Fz44P7QQGcDzqbsRoFsOwDgFrmKUDfpx7DMs1Ecv3rWk58kxsBbL80yzCzWvfHuJiCwTtaLXOCXNSpvtvFbM45SMLQBu5r8bxUavDqp40tburtjCRIfDna8hVqr8j7PnhITbMWU8ziS3jj6tMSgp51rFJXdB2UykjmwO8YaXn8J7aCovvQQhlq7m0rKgVjR4cgzZA+ZpODeXIS4Hxw3kEFozl1QIVxP0s1kC+a5DTtTP3zyN0fRUPTYAGH5y0r5ACYfdHisId44CV/ME1iseSUW7lAjJZs1WEv0/egPrjXkJNFCxcZ9yv6nbutaxhQiB4DEqettGzjlUg25mLbCqUZAtK3CcwS6xL8KzmjgBebrOI/oeVjuFJB0By0Cp65VKQ9bUvcEenje+07mkA+DxD1i0d0YwV61Gj4ewwzXAZ/FQy91iCYKexb9M1+Zk3K73pTC6alZICGT1hUumd6LRJvOGbpFKkBe+T/p7RmpK9NZ9XKL/xE/qk9; 4:tR7XS2QbkzDW1zlVfc3jcO/euAbd4VdrQX4Rop9+FJWSF40KY6yMggNpMg3u1bOYrhoLx39EfetEmTNpCCFDrTsGxTFR6UoYwhn0E2dUcQX6ni89lt5DpIDmfpNZ6tpxWNQaLWljMMBOa5OslsP+8oxm9tCbcivGXCcK37IxyBc67+c6mnMbtljgyX3UZ0ibBLKEMYlj4t61mBy3lVXqrGqD8Fi90CF01z6QJfCktAHuAPxQFZkE2JIJ+IDZ7aTwFilYZ3TV/ZdFN+2xPQPG2e8WsZF4RM/9Oy4+o2nNyyQE9snTUfAsd/nnpt5vE3FZ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(155532106045638); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3231022)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BL2PR06MB2212; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BL2PR06MB2212; X-Forefront-PRVS: 0492FD61DD X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(346002)(376002)(189002)(199003)(24454002)(7736002)(82746002)(33656002)(101416001)(229853002)(4326008)(50226002)(76176999)(50986999)(189998001)(316002)(478600001)(305945005)(6486002)(6246003)(105586002)(36756003)(106356001)(2950100002)(81156014)(8676002)(1706002)(8746002)(5660300001)(97736004)(53546010)(68736007)(47776003)(81166006)(2906002)(6666003)(83716003)(6116002)(86362001)(57306001)(25786009)(23726003)(50466002)(8936002)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR06MB2212; H:[IPv6:2001:67c:370:128:51bb:8db5:25b1:f6c5]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2PR06MB2212; 23:Ocp3q2gYBNqJ6cvqGaxFuzHZVvi6E1+WNN57GRwzt?= =?us-ascii?Q?XRueReIEeA1acu+cyigOm9kJUamVpILou+RU7mdPzLLB/p3Rc2Wa0TDfZ7Tv?= =?us-ascii?Q?BYw3gfhpq2FS2NQx+hod9TjY0x9UILKB4OPnqsV2hrj/c8piiq4kxyDKmdoH?= =?us-ascii?Q?CDLtscvBjMZ6E9MNjXpQ0LbDnOVG/P1SvBh2F7O3C3N0d1N8rwPLsdMp18p5?= =?us-ascii?Q?edvXg032i+k2ceQQ39US16ntLj5BrEVpT80YO9WjjdFY/Oc7w+eXFRGm0lSs?= =?us-ascii?Q?hv5Hc1nRR6q+/rb59RvA1q9uhwpVKte0gLLrchsMMvnsVNaOToTlZKnQ8Ye8?= =?us-ascii?Q?vxOD9BAJPnHnw5JleJSzwvdynXdne44+poJyCFtGIzq4CMu4DrcG7gbRiE6N?= =?us-ascii?Q?CGNyhEaLi0ATn3i6RgJ39ULRg0DbdyznWE3m+UiMtii209AJESmdh0vdm7Em?= =?us-ascii?Q?dLmYjarfisbGqI77ox+GRYjKSadcWMTWEg4BqoQXxCTo5vvXesjOm77eVo9f?= =?us-ascii?Q?0AqczE+kv3LONXdKcP3iVKGdTo7ad1SDwD16BHcZXMhCq5jqT8mSghFztlJk?= =?us-ascii?Q?ZuXmJbG8uzMjKRXQ6NP1DslYoKE9csRKWkFLsW8b6g+e/QRYpex9yTnw/fSd?= =?us-ascii?Q?obkOl32d4pUnmskWbntFJhooPBkwD1cUsVhk7B0S+bTg6Is0j6DvTnlsGraT?= =?us-ascii?Q?h+gAF7woxvmJTWy8RxYq/OTwsrvVseE/iu9ZJ51CWoOFs9I+iouuivGMMjSk?= =?us-ascii?Q?urdgTYv82VyEB/He81DJkSzQRp8IOCSZE9T+gTnKaXINPL4ZmYC4muXNJ+++?= =?us-ascii?Q?sNU+9DQ22GyEcbvSD5nTpydAWVosBrU9D9j0q6StB5Hsg2bxCjncNNUPVZ7j?= =?us-ascii?Q?i6oDj/35Qtg2eIeTsw7yigXP2Vvo6N6UhnmV0B5M1GEqGd4unf75dW/+jNio?= =?us-ascii?Q?INfIet+Ha5r5vFUSOCcKtueiXUEbZ7cbpws0wGv3r+10zBXclSSb9TGnWW7h?= =?us-ascii?Q?SCKCBt1EHZqdLvUTqnNeCcc+hsfzgysVcUrQsZVnQhi7c4jqZCwBW13UMyu8?= =?us-ascii?Q?0NGkaxZX1RRw7Sp7k2lyqC/FU5lvJzb4kBE4n5EXu3F9XE+Kbtp+PqGLLaJX?= =?us-ascii?Q?cwnI4cT1gY=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR06MB2212; 6:Yms4/co/M+7SDq2Z6Cp8aNmDpWxfxuXlECYMDWIXE1clKrWTlCIeYtJ8DquZykVEomk1zs+eAU2FYdkC+5LGlqQMyqrGHRPHGJgfURTrQA4m4IdwqhB1TDnt/imc3AMwQV5YiDpScQxF3YMjjdHHUacx2nAxRWVqcLn4YW5agIyaQkW+mwPjm3DB/lv0dywj9gtroafalna8jrNz0arNAXoPHxMB8btP3qohS24dXKr5GV5MmeOi0PqbnFvNZpwLR4XUDftDPNtG3eR5dCYYJa/fJXUVRBm7/eadsUBErWYTE1G0W/GErJuDF568+PPoFtjmvrCBXUYcRo0rvCxfiIVpeucpySxgoyn9gzlXAD4=; 5:Za0XlwhwTS5v5WR28L4nBqN+01tqL30uddW2PURLW4GrSvNCZhrLU8C32f2bmX2CQ+CPtj+JAwnGPsSyK5ELYe8FgUFKuwvJdq7p10z9eTrpF6/LgrtNBtpa1YCZz6Spyet5KI0gEH3/RLIMtf8EWZcHFfOtN+HRQI7mBh8nj1Q=; 24:aF21yVHbiNOv+frU0+fk2MHKEie1ojHkBoTwZ90e6H5MAIwRyeBE747joWBQ/g0X7EDTOU9zrCsCSTcfZCqQUXRW0HTK/FUgzvvpQw882xo=; 7:3X5rbY8Xki6QiwZ4n+VMzmMPnV5Zh/bFfCS8cd8yy++RqCV/fCRFL++3C6rpbcMVKBPay9ZbHivTllabwPI+CqLa2SWGYmQCZXrtSUHJGV05cI2dqqcwbPHfMYBhzVhQvflozlAYRAnBQz6q0NbV21P/kSdQYxeEKfPcwB40zhE+0oybYQi/JMaY9sxDS7gmegrNqHDsWIBVAo+4UxiJKoXs5hJsCUd9GybLVIX1xIroltChwHwdenKIG5tQ276k SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2017 03:47:54.9869 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 23b52fee-6445-478c-f340-08d52bdba81a X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR06MB2212 Archived-At: Subject: Re: [Iasa20] Raw minutes X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 03:48:03 -0000 > On 15 Nov 2017, at 02:49, Michael Richardson = wrote: >=20 > ISOC was created in great part so that the IETF > wouldn't have to [be an independent organisation] It would be helpful, to me at least, to get some insight into the extent = to which that is a true statement. Maybe someone in a position to do so = could ask Vint? Assuming it is true, what were the concerns then, and to what extent are = they no longer relevant in the various models being proposed for = IASA2.0? Mat= From nobody Tue Nov 14 20:32:36 2017 Return-Path: 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 68945128BBB for ; Tue, 14 Nov 2017 20:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XLcxqYOjf2Ra for ; Tue, 14 Nov 2017 20:32:33 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728CC126E64 for ; Tue, 14 Nov 2017 20:32:33 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id h42so9804164qtk.11 for ; Tue, 14 Nov 2017 20:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SbpjWXmNXTOfHV/PhDtZApRmXcQTKja5yVvmhKiZsgE=; b=Kx+0CSKLn/EsjhGiVvRag3F+aeu8lyRdlxyr3tSd5XUAvpNdAufxlIuLpE5QLHfehn H2y8qrRLGIUT3/ow7jvspi6Gn+QtSzWCV7nRinDzyl7jjAATcY9Dpjd8ZM6UfnjTZVpU syt/c9xKO23ofcqkX7E73tKHXl+Qs9ID9a+D5L1aMOL6yaLv4B/NwYevjKM+aECIvHoJ iN/udCnrVMwlzWW37451UnMuGiow6p+EMZvZG0HsHmZQCyignSjfenLESvW4QrUOpzju PG19EMZL3FBbl4uzw8H/GbG+CFWQmAXIUg+mlW+9SbXDRFVpsawMmD3b60utLiDD0bYf mX8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SbpjWXmNXTOfHV/PhDtZApRmXcQTKja5yVvmhKiZsgE=; b=kIYB5DLFr2su5V8EFoNB7f/i8x6tFHh8L4oxnMXOZLBO8KXRYT2wN13uD2Z6EXCxsn h1ODTL5V32rB6al1v1y98EBkRV4VwcokncBsy1F2gTzLQsRla7AmFA12DMwH/+5OCH8x Ag18R4LJ0fk1tWn331EB1wmuuNtWYiHWoMx1JuWTJAc0/IUU3AjW/1q5QupREX1buYFB /XfwQbmP3nrIFwDbhZS5iTjcLks41TuDDSIRwPD3CQSdtuNwMmqlxpbR/wa8d92Cwaf4 F8CqqVE9a8XzVYnlzKCYDQM0kEoNoXZC4+CUeNExunS7y2zCQQ2zBzaW818aU3i0v66D Nc+w== X-Gm-Message-State: AJaThX65495HmM4VJa8/XKngiZ9/ed99+hlRS3d0fx1U8OXPjhlsTFuk di0CCUWAzNhbHblxp7ZHqekHPqYzzVVFgLEkMxU= X-Google-Smtp-Source: AGs4zMaqOXdZutqCqm/KAzCg8ifYDk/4rUglytrow7+jdtabh923j8OOZ5YfnDBvojY8XPNOBENWKrsJovmQ3wHt3eM= X-Received: by 10.200.35.173 with SMTP id q42mr9303665qtq.199.1510720352423; Tue, 14 Nov 2017 20:32:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.3.97 with HTTP; Tue, 14 Nov 2017 20:32:01 -0800 (PST) In-Reply-To: <095ABCC8-91EB-427F-91FD-96B49BF2CFC7@isoc.org> References: <16708.1510685383@obiwan.sandelman.ca> <095ABCC8-91EB-427F-91FD-96B49BF2CFC7@isoc.org> From: Ted Hardie Date: Wed, 15 Nov 2017 12:32:01 +0800 Message-ID: To: Matthew Ford Cc: Michael Richardson , iasa20@ietf.org Content-Type: multipart/alternative; boundary="001a1142f08af612ca055dfdfdf5" Archived-At: Subject: Re: [Iasa20] Raw minutes X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 04:32:35 -0000 --001a1142f08af612ca055dfdfdf5 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 15, 2017 at 11:48 AM, Matthew Ford wrote: > > > > On 15 Nov 2017, at 02:49, Michael Richardson > wrote: > > > > ISOC was created in great part so that the IETF > > wouldn't have to [be an independent organisation] > > It would be helpful, to me at least, to get some insight into the extent > to which that is a true statement. Maybe someone in a position to do so > could ask Vint? > > It's covered in http://ethw.org/Oral-History:Vinton_Cerf In the transcript, see the section at the end of "Corporation for National Research Initiatives and a self-supporting Internet" and the beginning of "The Internet Society, return to MCI". > Assuming it is true, what were the concerns then, and to what extent are > they no longer relevant in the various models being proposed for IASA2.0? > > I think Vint is on his way to Antarctica, but you're welcome to send email if you need more clarification. regards, Ted > Mat > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 > --001a1142f08af612ca055dfdfdf5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 15, 2017 at 11:48 AM, Matthew Ford <ford@isoc.o= rg> wrote:


> On 15 Nov 2017, at 02:49, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>
> ISOC was created in great part so that the IETF
> wouldn't have to [be an independent organisation]

It would be helpful, to me at least, to get some insight into the extent to= which that is a true statement. Maybe someone in a position to do so could= ask Vint?



In the transcript, see the section at the end= of "Corporation for National Research Initiatives and a self= -supporting Internet" and the beginning of "The Internet Society, return to MCI&q= uot;.
=C2=A0
Assuming it is true, what were the concerns then, and to what extent are th= ey no longer relevant in the various models being proposed for IASA2.0?


I think Vint is on his way to Antarctica, b= ut you're welcome to send email if you need more clarification.

regards,

Ted

=C2=A0
Mat
_______________________= ________________________
iasa20 mailing list
iasa20@ietf.org
https://www.ietf.org/mailman/listinfo/iasa20

--001a1142f08af612ca055dfdfdf5-- From nobody Tue Nov 14 20:34:29 2017 Return-Path: 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 58DA7128BBB for ; Tue, 14 Nov 2017 20:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 We4mK9kD7W_R for ; Tue, 14 Nov 2017 20:34:26 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20653126E64 for ; Tue, 14 Nov 2017 20:34:17 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id a84so11222925pfl.0 for ; Tue, 14 Nov 2017 20:34:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2FDrEjDY55gslKm/yDEhG2e/1GXM/9H3q0zecuBQ48k=; b=G66NvRekPT5GJ4VfwrHUCBuz6a1+F2dj1oDuVLxlTJfqcJU9UJs3b7hX88+38iS0QI ejgx2W9L9IJHwvXap8QaWqlCQPDq/TTFZFpd2+GqLv5/iiWA4Lr6bEzQmSMHoUKlzJx7 TZfnWWsxYS5w7xrxOjREVf95rc+aibr9tEKtI5PC1iT0zDw7khcj9DiYBUsn5z6/5wpB gbtWzKxYhu4xP6/8c3vgvvoKRObMeCKl0Ul/gXthMw3gf6aja9jwuwH41iNf1Z1TuGql AA+iSq+IreYIEGSWulR44aKH+rILxG1TrQxbesgmKZY09TeHp0/r3GMLXm3XI6KPkcJy 34mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=2FDrEjDY55gslKm/yDEhG2e/1GXM/9H3q0zecuBQ48k=; b=qk7lk5HGMfKQ59UuyoxB2pI0UNKcyEsSf2iEMvHyF2LfrrIytKDVzsbsvZZz4nXdUs ml29dUIrUJF1HHuKPo8YiUm9hCVVKLgKf5rNa7Iv9Djy3kdEj/AkscJkpTZb4eBznH80 5qpdyKwT++DwLKVJ9nCbj1IqVf+ei6UePY/P9x+LraJsXXezSevlwUNfFVJ34aIa4Il5 aHXuR5slA1mNbU7t6YO+rdD92Rbf91jUA1vYXwazGaSzEz2bIkbi/WqRl5kZgL1EQm5m yECVnDUHa6qNloQEh2g3/it56wYdDziGobMNp7L96FedgCWH8d3IOO3jX0g8FXPtwQXR MVLA== X-Gm-Message-State: AJaThX6mfxiW5HcmDaJBrcba8ZmiNtl0P9j+GuG2tf0nlyGGwHrctGPI /yT6S/jjBbLhMn+sP17DiHX6Tw== X-Google-Smtp-Source: AGs4zMY99f4+p9WkrbmCDtg8d8XXfPmrc0JXGidVYbQqmRTaFtrAh3a4yhDGwm4rTDQQuxS/FMFGeQ== X-Received: by 10.84.196.3 with SMTP id k3mr14565237pld.237.1510720456329; Tue, 14 Nov 2017 20:34:16 -0800 (PST) Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id z71sm32201006pfi.172.2017.11.14.20.34.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 20:34:15 -0800 (PST) To: Matthew Ford , Michael Richardson Cc: iasa20@ietf.org References: <16708.1510685383@obiwan.sandelman.ca> <095ABCC8-91EB-427F-91FD-96B49BF2CFC7@isoc.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 15 Nov 2017 17:34:16 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <095ABCC8-91EB-427F-91FD-96B49BF2CFC7@isoc.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Iasa20] Raw minutes X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 04:34:28 -0000 On 15/11/2017 16:48, Matthew Ford wrote: > > >> On 15 Nov 2017, at 02:49, Michael Richardson wrote: >> >> ISOC was created in great part so that the IETF >> wouldn't have to [be an independent organisation] > > It would be helpful, to me at least, to get some insight into the extent to which that is a true statement. Maybe someone in a position to do so could ask Vint? Speaking as an ISOC pioneer member from 1992, I believe that this is a true statement. ("in great part" != "only"; there were other goals too.) > > Assuming it is true, what were the concerns then, and to what extent are they no longer relevant in the various models being proposed for IASA2.0? I wasn't involved in those discussions, but from what I heard starting in late 1992 at my first IETF (#25), the idea was to avoid loading the IETF with all the concerns of creation and governance of a formal organization, and at the same time give corporations, formal standards organizations and governments an entity they felt able to deal with. Thus the IETF Chair (Phill Gross) and the IESG could focus on cat herding and the technical work. This is why option 3, which we dumped yesterday, was very scary since it amounted to creating a new instance of ISOC. IASA as it was set up in 2005 was aimed at fixing various problems that the 1992 reorganization didn't address. And they are documented: https://tools.ietf.org/html/rfc3716. It took a year's hard slog after that to publish RFC 4071 and hire the first IAD, and some months longer to establish a clear contract for the Secretariat, create the IETF Trust, and transfer the relevant IPR to the Trust. IMHO, YMMV, etc. Brian From nobody Tue Nov 14 21:02:33 2017 Return-Path: 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 1334C127873 for ; Tue, 14 Nov 2017 21:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 E0SpEJtGDY1i for ; Tue, 14 Nov 2017 21:02:30 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016B81242EA for ; Tue, 14 Nov 2017 21:02:30 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id s75so17181747pgs.0 for ; Tue, 14 Nov 2017 21:02:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=TUHYQMLvPYtnsJDzAgMWcSLmwAmKNaWaiAYpRambMEU=; b=h4EZJ0jXLGLH9l2tEoPaGPfablsD9M4eReuNwHb69D8ymNqGP28TxZfvqaNcFqxJSa qq48YKcv0QdLpZmNjXcdJzB8voRLt/hYD2e+cI/ZfpILPwvG6VruPOrGQ472YrfJ+yWn kiixLc70r+dWZWSsRL4nl6c2YZVbAaALEcVn8sNfyOTnnXhMX4dodyP5C/5TJi6dGxk9 934VEJxNY9Y61z3XFvDBtFEb0mxGSbdH1jeHZWTjhyEtt/vi10nhEPSJ2vKMTXL95WJ3 gDOxpCVNtRJTuh4En9zHX/+zFYLEpGy1clXGEXn+t+u3KGBiIkju4IYJGK/uFeTQ5rNX YKLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=TUHYQMLvPYtnsJDzAgMWcSLmwAmKNaWaiAYpRambMEU=; b=VJId0ehGSp7WxHCDv7m587L9Gie7uRfjyoDyyxiVNTCjcSikgxN2Bi8nGYj63Miu3C 3R+P4eCubVFjklMw7f67FjFGaLdoD2yJ6duySjTvQLorGdNC7HtHubaHMQ6k7DF77dMd CyaQeliLNbRjjSu4JNkHfBc15rcEzJ5VAKAyPgyfw27lS0Y3bQqXUE65JQK050q3ev+B WWE0Xit1TxdSYPUX55Uh4ai3W2Dx+1d8qYeve0O9+XdBbKZlo2jc0JSamdMYWWlUNIR6 D45IG5TG8KwZHcwK+isDh/yXn/OK00n27385cajmg63srXEXRygf/obR3RbLHpypxAWF N3bQ== X-Gm-Message-State: AJaThX4apGedyq2JTvys4q7YEa8cLo4EqQ/B9QA4TnJCTdnBRL4ITUFQ Wc+zl1lIHsVLIHK+qKoxrOo= X-Google-Smtp-Source: AGs4zMa1bUYLqHoZqpeA+tnrjcuG7QjhVjfeuxd/6ZGjVzGCo5IcFfqJufOI0Iy5ehZEAbYkiRZmtQ== X-Received: by 10.84.128.227 with SMTP id a90mr6644418pla.224.1510722149582; Tue, 14 Nov 2017 21:02:29 -0800 (PST) Received: from ?IPv6:2001:67c:370:1998:3d16:cfb2:a3bd:e86f? ([2001:67c:370:1998:3d16:cfb2:a3bd:e86f]) by smtp.gmail.com with ESMTPSA id w5sm39583014pfw.51.2017.11.14.21.02.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 21:02:27 -0800 (PST) From: Bob Hinden Message-Id: <42A36B2C-B898-411B-A6FE-478A49D7C8CB@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_68334C07-4640-41EA-9731-9B614E2D5D56"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 15 Nov 2017 13:01:22 +0800 In-Reply-To: Cc: Bob Hinden , Matthew Ford , Michael Richardson , iasa20@ietf.org To: Brian Carpenter References: <16708.1510685383@obiwan.sandelman.ca> <095ABCC8-91EB-427F-91FD-96B49BF2CFC7@isoc.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Iasa20] Raw minutes X-BeenThere: iasa20@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 05:02:32 -0000 --Apple-Mail=_68334C07-4640-41EA-9731-9B614E2D5D56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, > On Nov 15, 2017, at 12:34 PM, Brian E Carpenter = wrote: >=20 > On 15/11/2017 16:48, Matthew Ford wrote: >>=20 >>=20 >>> On 15 Nov 2017, at 02:49, Michael Richardson = wrote: >>>=20 >>> ISOC was created in great part so that the IETF >>> wouldn't have to [be an independent organisation] >>=20 >> It would be helpful, to me at least, to get some insight into the = extent to which that is a true statement. Maybe someone in a position to = do so could ask Vint? >=20 > Speaking as an ISOC pioneer member from 1992, I believe that this > is a true statement. ("in great part" !=3D "only"; there were other > goals too.) As another ISOC pioneer member from 1992, I agree. One of the reasons = ISOC was formed was to support the IETF, but it wasn=E2=80=99t the only = reason. More importunately, ISOC has supported the IETF since then, and = as far as I can tell wants to continue to support the IETF in the = future. Bob >=20 >>=20 >> Assuming it is true, what were the concerns then, and to what extent = are they no longer relevant in the various models being proposed for = IASA2.0? >=20 > I wasn't involved in those discussions, but from what I heard starting > in late 1992 at my first IETF (#25), the idea was to avoid loading the > IETF with all the concerns of creation and governance of a formal > organization, and at the same time give corporations, formal standards > organizations and governments an entity they felt able to deal with. > Thus the IETF Chair (Phill Gross) and the IESG could focus on cat > herding and the technical work. >=20 > This is why option 3, which we dumped yesterday, was very scary > since it amounted to creating a new instance of ISOC. >=20 > IASA as it was set up in 2005 was aimed at fixing various problems > that the 1992 reorganization didn't address. And they are documented: > https://tools.ietf.org/html/rfc3716. It took a year's hard slog after > that to publish RFC 4071 and hire the first IAD, and some months > longer to establish a clear contract for the Secretariat, create the > IETF Trust, and transfer the relevant IPR to the Trust. >=20 > IMHO, YMMV, etc. > Brian >=20 > _______________________________________________ > iasa20 mailing list > iasa20@ietf.org > https://www.ietf.org/mailman/listinfo/iasa20 --Apple-Mail=_68334C07-4640-41EA-9731-9B614E2D5D56 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloLyiIACgkQrut0EXfn u6gKtAf/VoxjsSwXJzl6ny6SRblgL+iEN2fG5tVAAAhiJSiCE1qXspXBawsEMqKL TX8BJOashoSR8yrRo5lnzdiOo0onhokzwwgpY16SOPy79HWOuuE6qioc5tZYGp2e ZAhisEznh6LORUTuEQSWxinIe9mBAjIZYTAQDOMeKwo90p8zqc7NFk8wCblcv6ve lSnpxHI0PXdXudqRJBO9UG7rRPdDppmF2H5xPouGtaNVxcIRqVzj1nncqDrRkQ48 +jETQAH4nSW5dKFgKE6R9NGwKCyRDHmdSYPHYrieFMO5+7+/lxNA/XnW0QgzoMwO fDOjTqurUPW9z6BRQbJRoYRTOeGG5w== =5mh+ -----END PGP SIGNATURE----- --Apple-Mail=_68334C07-4640-41EA-9731-9B614E2D5D56--