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
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.
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
dcrocker a t ...
Ietf mailing list