RE: isoc's skills

Dave Crocker <dhc2@dcrocker.net> Wed, 13 October 2004 01:46 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 VAA07468; Tue, 12 Oct 2004 21:46:58 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHYP7-0000VJ-Bk; Tue, 12 Oct 2004 21:58:13 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHY9T-0005uT-09; Tue, 12 Oct 2004 21:42:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHY5l-0004yb-9K for ietf@megatron.ietf.org; Tue, 12 Oct 2004 21:38:13 -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 VAA06549 for <ietf@ietf.org>; Tue, 12 Oct 2004 21:38:11 -0400 (EDT)
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHYGb-0000Ln-87 for ietf@ietf.org; Tue, 12 Oct 2004 21:49:25 -0400
Received: from bbprime (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11/8.12.11) with SMTP id i9D1bdRr023164; Tue, 12 Oct 2004 18:37:40 -0700
From: Dave Crocker <dhc2@dcrocker.net>
To: Tony Hain <alh-ietf@tndh.net>
X-Mailer: PocoMail 3.2 (2000) - EVALUATION VERSION
X-URL: http://www.pocomail.com/
Date: Tue, 12 Oct 2004 18:37:37 -0700
Message-ID: <20041012183737.824836@bbprime>
In-Reply-To: <200410111910.i9BJA43O021328@sb7.songbird.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: RE: isoc's skills
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: 5d7a7e767f20255fce80fa0b77fb2433
Content-Transfer-Encoding: 7bit

Tony,

Thanks for the followup.


>  You are correct we need a detailed documentation of the
>  interface before we deal with any corporate entity. As I see
>  it the differences between your opinion and others has more
>  to do with your focus on the interface than the
>  organizational structure others are commenting on.

My focus is on knowing what the details of the jobs are that we
want done. Referring to the interface(s) is a convenient
technique for trying to surface those details.

Currently we do not have the details.  What we are doing is like
buying a building or a vehicle before we really understand
what uses they are going to be put to.  This leads to thinking
that those details are trivial.  They aren't.

Privately I have been accused of carrying some sort of grudge
against ISOC.  That reaction is unfortunately typical for these
discussions. One cannot ask basic, entirely pro forma questions
about needs and competence without being discounted as carrying
a grudge.

In a very basic way, I think the question of ISOC is irrelevant.
It cannot become relevant until a) we have a substantial
specification of the work to be done and b)  a precise statement
of how a candidate (ISOC) will do it.

So far, anytime someone asks about either, they get no answer or
they get a handwave.  If they press further, the answer changes.

Really.  The lack of substance is astonishing.

I am trying to imagine any of us making even the most
simple purchase of a service with this little comprehension of
what we were buying.


>  reaction to your concern about ISOCs track record was that
>  the IETF itself has even less of a track record, and a poor

That hardly seems like justification for handing the task to ISOC
-- or anyone else who is inexperienced or has done the job badly.

In fact I thought the whole idea was to have this change get
things done better and more easily.  How can we believe that is
going to happen?


>  one at that. Despite the legal difference between the
>  Administrative office being a separate corporation vs.
>  incorporating the IETF itself, the backers of both of those
>  choices appear to assume the IETF will directly deal with the
>  financial issues because their arguments against outsourcing

The key word is 'assume'.

The problem is there is a) no substance to the assumptions, and
b) each person seems to be making different assumptions about
what the substance will turn out to be.

Try imagine writing a protocol spec with that little shared
understanding of what job it is to do.


>  all say 'they have a different focus'. As several people have
>  stated, the IETF participants have a technical skill set and
>  no demonstrable skills at financial administration. Why then
>  are people so quick to point out that outside organizations
>  have a different focus when our internal skill sets don't
>  match the need?

Because it is our organization.

Ultimately it is our responsibility to make it work.

And, by the way, some of the IETF leadership pretty much
explicitly expect the contractor to do all the financial work.
Or at least that is what I have heard some of them say.


>  Yes before we go off and sign agreements we need to know what
>  the details of those agreements will be.

Sorry, no.

Before we make strategic choices it is our responsibility.  And
that means before we even go out for 'bids'.

If we only worry about the details after we have chosen the
contractor, we will probably choose the wrong contractor and we
certainly will not have any negotiating leverage.



>  Others may add to the list, but taken collectively it should
>  be clear that scenario C is fundamentally the end of the IETF

Whereas I guess I would say that the end of the IETF is working
on the the list of scenarios, because that list is based on
ignorance of the work to be done.

When we know what the work is, we can consider how to get it
done.

d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
www.brandenburg.com



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