Re: What to incorporate (Re: Options for IETF administrative restructuring)

Carl Malamud <carl@media.org> Thu, 02 September 2004 14:20 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 KAA06975; Thu, 2 Sep 2004 10:20:51 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2sUk-00081j-8o; Thu, 02 Sep 2004 10:23:22 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2sFb-0007I6-UD; Thu, 02 Sep 2004 10:07:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C2s6W-0007ua-9J for ietf@megatron.ietf.org; Thu, 02 Sep 2004 09:58:21 -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 JAA04149 for <ietf@ietf.org>; Thu, 2 Sep 2004 09:58:18 -0400 (EDT)
Received: from bulk.resource.org ([192.101.98.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C2s8u-000624-Hd for ietf@ietf.org; Thu, 02 Sep 2004 10:00:49 -0400
Received: from bulk.resource.org (localhost.resource.org [127.0.0.1]) by bulk.resource.org (8.12.2/8.12.2) with ESMTP id i82Dtn6Y029472; Thu, 2 Sep 2004 06:55:49 -0700 (PDT)
Received: (from carl@localhost) by bulk.resource.org (8.12.2/8.12.2/Submit) id i82DtnrC029471; Thu, 2 Sep 2004 06:55:49 -0700 (PDT)
From: Carl Malamud <carl@media.org>
Message-Id: <200409021355.i82DtnrC029471@bulk.resource.org>
In-Reply-To: <20040902112648.834F836FB43@newdev.harvard.edu>
To: Scott Bradner <sob@harvard.edu>
Date: Thu, 02 Sep 2004 06:55:49 -0700
Organization: Memory Palace Press
X-Winch: Warn 9.5i
X-Mailer: ELM [version 2.4ME+ PL94 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: What to incorporate (Re: Options for IETF administrative restructuring)
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: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit

> 
> Harald sed:
>    scenarios C and D envision incorporating the *support function* for the 
>    IETF. The IETF would remain an undefined entity under these scenarios.
> 
>    I've had another suggestion that the IETF (the real technical process 
>    entity) should become a formally recognizable entity of some sort (possibly 
>    an unincorporated organization). But that's distinct from the idea of 
>    incorporating the support function, and is NOT described in the current 
>    document.
> 
> imho both C & D would be seen by most or the world as incorporating 
> *the IETF*  - if there is confusion within the IETF over the
> difference between incorporating the *support function* and 
> incorporating the whole IETF the difference would be totally lost
> by non-IETFers (and most IETFers is my guess) - in any case, the 
> target of any legal attack on the IETF would be the corporation with 
> IETF in the name if one existed - about the only way I could see that
> there woudl not be confusion wiuld be to call the corporation "The
> Corporation to Support Internet Standardization" (TCTSIS or TCSIC) and
> not have the IETF name in it.
> 

Perceptions are always important.  Under Scenario's A and B, likewise,
the Internet Society probably gets to be a target.

On the other hand, one benefit of incorporating an entity, such as
an administrative support structure, is you can, to some extent,
insulate yourself from frivolous attacks.  You can also limit
liability on non-frivolous attacks.  Just as importantly, you
have standing to enforce agreements, such as contracts with
support organizations.

Harald mentioned some other structures available.  One possibility is
the "unincorporated association" on which I've been doing some research.  It
will be in my next rev of the report, but people are always welcome to look
at the work in progress:

http://public.resource.org/adminrest/

-01 is the unpublished work in progress.  "Scenario E" discusses the
concept of the unincorporated association.  Comments are welcome.
I expect to put this next rev into the i-d queue on Monday.  I still
have some cleanup to do to incorporate comments by Bob Kahn and
Brian Carpenter, and am trying to clean up the RFP stuff to make
it a bit clearer.

Regards,

Carl

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