RE: AdminRest: IASA BCP: do we need dedicated IASA (bank) account s

"Peterson, Jon" <jon.peterson@neustar.biz> Fri, 26 November 2004 21:32 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 QAA25164; Fri, 26 Nov 2004 16:32:16 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXnlp-0007t8-2i; Fri, 26 Nov 2004 16:36:49 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXndB-0002K6-AC; Fri, 26 Nov 2004 16:27:53 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXncc-0002FB-Bn for ietf@megatron.ietf.org; Fri, 26 Nov 2004 16:27:18 -0500
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 QAA24861 for <ietf@ietf.org>; Fri, 26 Nov 2004 16:27:16 -0500 (EST)
Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXngy-0007hv-KJ for ietf@ietf.org; Fri, 26 Nov 2004 16:31:48 -0500
Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id iAQLQixg014281; Fri, 26 Nov 2004 21:26:45 GMT
Received: by stntimc1.neustar.com with Internet Mail Service (5.5.2657.72) id <XKK71ZCR>; Fri, 26 Nov 2004 16:26:45 -0500
Message-ID: <24EAE5D4448B9D4592C6D234CBEBD597089971@stntexch03.cis.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'sob@harvard.edu'" <sob@harvard.edu>, ietf@ietf.org
Date: Fri, 26 Nov 2004 16:26:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Subject: RE: AdminRest: IASA BCP: do we need dedicated IASA (bank) account s
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: 769a46790fb42fbb0b0cc700c82f7081

Scott,

> as I just posted in response to a different posting from Bert
> I think these are not the right questions - that these questions are
> being asked is a symptom to me that the document (and maybe the IETF)
> is not yet clear on the principals we want to have agreed to for
> going forward - I think the whle question of a bank account
> is an implementation detail that the people "on the ground" (IAD
> etc) should figure out - the IETF should figure out what are
> we trying to accomplish and describe that clearly
> 
> Scott

Well, let me say what I think these questions are symptomatic of (quoting
from draft-iab-iesg-adminrest-rec-00):

   Scenario A worried people because it did not seem to acknowledge the
   IETF community's need to be able to determine if its needs were being
   met and to do something about it if they were not - the phrase
   "replace existing problematic structures by ISOC" was perhaps a
   capsule summary. 

I think there is a concern in the community that the IETF needs some way to
ensure that it is not "locked in" to any solution we adopt at this stage.
After all, it has been a complex and somewhat contentious road to where we
are now, and while we've arrived at a consensus on a plan, we can't be
certain that the community will think it is the right course for all time to
come. Scenario O was adopted as a compromise position between A and B, but I
don't think we should lose sight of the reasons that Scenario A was
considered problematic in the first place.

Is the question of an IASA bank account an implementation detail? From my
perspective, it is one way to build in a degree of autonomy that would
enable to the IETF to react to changing circumstances; certainly, it seems
likely that the IETF's ability to react would be impaired by a lack of
direct control over its assets. But as you say, the principle is what is
important here. So I guess the question is, presuming people largely agree
with the concern articulated about Scenario A above, how would you recommend
that we guarantee the IETF's ability to react?

Jon Peterson
NeuStar, Inc.

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