Re: Upcoming: further thoughts on where from here

Ted Hardie <hardie@qualcomm.com> Tue, 21 September 2004 18:09 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06726; Tue, 21 Sep 2004 14:09:34 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9pBV-00006R-2X; Tue, 21 Sep 2004 14:16:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9p2b-0007sP-8B; Tue, 21 Sep 2004 14:07:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C9os5-0005jS-85 for ietf@megatron.ietf.org; Tue, 21 Sep 2004 13:56:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05930 for <ietf@ietf.org>; Tue, 21 Sep 2004 13:56:08 -0400 (EDT)
Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C9oyU-0008Lv-JP for ietf@ietf.org; Tue, 21 Sep 2004 14:02:47 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i8LHtW57017824; Tue, 21 Sep 2004 10:55:33 -0700 (PDT)
Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i8LHtT1I011515; Tue, 21 Sep 2004 10:55:30 -0700 (PDT)
Mime-Version: 1.0
X-Sender: hardie@mage.qualcomm.com
Message-Id: <p06110402bd7615db394a@[129.46.227.161]>
In-Reply-To: <p0602043cbd75d138cf27@[192.168.2.2]>
References: <414EDAA2.9080205@thinkingcat.com> <414FEFFE.7090404@zurich.ibm.com> <85DDA364DCE0FE2485763318@B50854F0A9192E8EC6CDA126> <p0602043cbd75d138cf27@[192.168.2.2]>
Date: Tue, 21 Sep 2004 10:55:28 -0700
To: Margaret Wasserman <margaret@thingmagic.com>, Harald Tveit Alvestrand <harald@alvestrand.no>, Brian E Carpenter <brc@zurich.ibm.com>, Leslie Daigle <leslie@thinkingcat.com>
From: Ted Hardie <hardie@qualcomm.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: ietf@ietf.org
Subject: Re: Upcoming: further thoughts on where from here
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3

At 9:07 AM -0400 9/21/04, Margaret Wasserman wrote:
>Hi Harald,
>
>At 12:04 PM +0200 9/21/04, Harald Tveit Alvestrand wrote:
>>I've seen some argument that Scenario C, being more well-defined, 
>>is actually less complex than Scenario O.
>
>I share Brian's belief that Scenario C is more complex.  The 
>document for Scenario C currently focuses on the mechanics of 
>incorporation (as it should, I think) so it doesn't delve into some 
>of the topics that Scenario O covers, such as what decisions will be 
>made at each level of the resulting corporation. Since we will 
>maintain a relationship with ISOC for funding, the work required for 
>Scenario C is really a superset of Scenario O.

For what it is worth, I think "superset of Scenario O" is the wrong way to
capture this.  The work required for Scenario C may be greater than Scenario
O, but there are ways in which it is different.  The main difference here is
that any variant of "IASF is part of ISOC" deals with ISOC's corporate
realities, where any variant of "IASF is not part of ISOC" deals with
creating the appropriate corporate realities.  A major disagreement
that we seem to have is whether any additional work that may be required to
create the appropriate corporate realities is worth the options it
buys now and options it allows us to buy in the future.

I, personally, believe it does.  The functions intended for IASF are
different from those associated with ISOC, and I believe that it
will need to evolve over the next 25 years of the IETF's history
in ways that will either 1) constrain how ISOC must evolve,
2) constrain they ways in which the IASF can evolve, 3) cause
some later set of poor bozos to have to go through this same
exercise again.  I think 1) is a bad idea because I believe it will
reduce the effectiveness of ISOC (because fate-sharing with
IASF will mean the ISOC will have to be more risk-averse and/or distracted);
I also believe it is out of the IETF community's control.  I think
2) implies a risk that IASF will be constrained in ways that means
it will not meet the IETF community's needs (though I freely grant
that assessing the extent of that risk is nearly impossible).  I
think 3) is tempting, but that we ought to be nicer to our
successors than that.

Again, none of this is any criticism of ISOC in its role in the standards
process, policy, or educational realms.  I just don't see the need
to yoke these two horses together; to me, they do or may need to
pull in different directions.


Speaking personally,
			regards,
				Ted Hardie


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf