Re: IETF Administrative Reorganization: What was that problem anyway?

Carl Malamud <carl@media.org> Wed, 15 September 2004 14:26 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 KAA07418; Wed, 15 Sep 2004 10:26:22 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7aow-0004Ue-FK; Wed, 15 Sep 2004 10:31:42 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7aUY-0004X1-9b; Wed, 15 Sep 2004 10:10:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C7aM3-0001NV-Hq for ietf@megatron.ietf.org; Wed, 15 Sep 2004 10:01:52 -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 KAA05007 for <ietf@ietf.org>; Wed, 15 Sep 2004 10:01:49 -0400 (EDT)
Received: from bulk.resource.org ([192.101.98.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C7aRA-00044g-QH for ietf@ietf.org; Wed, 15 Sep 2004 10:07:09 -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 i8FDxJ6Y024973; Wed, 15 Sep 2004 06:59:19 -0700 (PDT)
Received: (from carl@localhost) by bulk.resource.org (8.12.2/8.12.2/Submit) id i8FDxJOo024972; Wed, 15 Sep 2004 06:59:19 -0700 (PDT)
From: Carl Malamud <carl@media.org>
Message-Id: <200409151359.i8FDxJOo024972@bulk.resource.org>
In-Reply-To: <1BAA2A8E7E650C991C575C8D@scan.jck.com>
To: John C Klensin <john-ietf@jck.com>
Date: Wed, 15 Sep 2004 06:59:19 -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: 3be09dac38eaa50f02d21c7fcee1128c
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: IETF Administrative Reorganization: What was that problem anyway?
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: f1405b5eaa25d745f8c52e3273d3af78
Content-Transfer-Encoding: 7bit

John -

Would it be fair to summarize your note by saying it is a
lightweight scenario A?  E.g., simply take one action: hire
an administrative director for the IETF and have that person
live at ISOC.  RFPs, budgets, etc... will all flow out of that 
initital action and there is no need for a grand restructuring.

Let me know if you think that is a fair assessment.  I think
that is an important option that people should keep in mind
and wanted to make sure that I don't oversimplify your
analysis.

Regards,

Carl


> In trying to parse both Carl's document and the general
> situation in the last few weeks, I've found myself getting
> increasingly dissatisfied with the document and the discussion,
> mostly with regard to ways in which the document has
> constrained the discussion and was, itself, constrained by RFC
> 3716 (the "AdminRest" report) and what it is believed to say.
> As a member of the committee that put 3716 together (but
> speaking only for myself), I think it is subject to the same
> sort of rules that apply to the relationship between our
> "model" or "requirements" documents and subsequent actual
> protocol work: if we discover in protocol development that the
> models are inappropriate or unimplementable, we change the
> models rather than considering ourselves locked to them.  In
> fairness to Carl, this is an option he didn't have: the
> contract held him fairly closely to RFC 3716.
> 
> Disclaimer: the comments below, and in my next note, draw,
> without attribution, on a lot of virtual and physical
> in-the-hall conversations.  I'll let the contributors identify
> themselves if they like, but I probably could not do so
> accurately and don't think it would be particularly helpful at
> this point.   I have been working on these notes for a week or
> so, and, while related pieces have shown up in on-list comments,
> I've changed my mind several times about whether to send it.  A
> few comments in the last 72 hours have convinced me it is time.
> 
> While I think the complexities of Carl's "simple" solution
> calls for reconsidering some of the conclusions of 3716 (or at
> least a more intensive community review of those conclusions),
> that document hints at the issue here in its section 4.1:
> 
>    o  nevertheless, it remains a non-goal to create an
>       organizational entity that exists simply for the purpose
> 	  of continuing to exist. This should be executed with the
> 	  minimum formality needed in order to address the
> 	  identified requirements. 
> 
> Stripped of a good deal of speculation about organizational 
> structures and arrangements, the key to 3716 and the concerns
> that surrounded it seems to me, again in retrospect, to be
> exactly two problems:
> 
> 	(1) For a number of policy and budgetary reasons, having two
> 	revenue sources that have to be kept isolated from each
> 	other lies on a scale between "suboptimal" and "nuts".  One
> 	of those streams is the meeting registration fees and their
> 	allocation to secretariat support as well as meeting costs.
> 	The other involves donations and other funds collected by
> 	ISOC and dedicated to non-Secretariat IETF support.
> 
> 	(2) The IESG perceives that they are not getting adequate
> 	support for their work, and the standards process more
> 	generally, from the Secretariat and that, despite
> 	considerable effort, there has been little progress on
> 	solving that problem.  The efforts to do so go back many
> 	years, including six to eight years or more of unsuccessful
> 	attempts to work out a statement of relationships and
> 	authority, in the form of an MOU, with CNRI and then with
> 	Foretec.    As I have mentioned in another note, the key
> 	difficulties in that process seem to hinge on fundamental
> 	philosophical disagreements about the nature of the
> 	relationship.  Independent of the causes, details, and how
> 	we got here, some fraction of the IESG and IAB now believe
> 	that the relationship with the secretariat has become
> 	sufficiently poisoned that a significantly better
> 	relationship is not possible with the existing Secretariat
> 	and its management.  
> 
>     It is worth noting that, from the Secretariat's viewpoint,
> 	it is likely that uncertainties about the administrative
> 	reorganization process and their future have made it
> 	impossible to do the job well and, in particular, to do any
> 	long-term planning.  From that perspective, part of the
> 	problem is that the IETF has put them in a position of
> 	making it impossible to do long-term planning, and then
> 	complained that they are not doing long-term planning.  But
> 	the problems that are impeding the IESG's work and the
> 	standards process were significant long before the
> 	reorganization process began.
> 
> Those two issues, especially the second, have a fairly clear
> negative impact on our ability to produce good-quality
> standards efficiently.  Aspects of it intrude on IESG
> efficiency and throughput, on the frequency with which things
> get lost or fall through the cracks, on interactions with
> meeting sponsors, on liaison relationships with other
> organizations and with problems in document handling as well as
> with comparatively trivial issues such as inability to keep
> restrictions on posting to mailing lists in place.  Nothing
> else of an administrative support nature seems to be on that
> particular critical path.  In particular, questions about,
> e.g., "what to incorporate" seem seriously peripheral to the
> real question: how do the proposals of Carl's document help us
> get better standards or get them more efficiently?
> 
> It also seems to me that the "need for the IETF to control its
> own destiny" is not a problem or goal.  It is a nice slogan and
> a source of confusion, maybe bordering on FUD.  But there is an
> interesting element of every standards body (as distinct from
> consortium) I've been able to remember or discover.  Either they
> are part of governments or they are closely linked to a
> "sponsor" organization.  The sponsor organization model protects
> the standards body from being directly involved in fund-raising
> and other activities that would give the appearance (or worse)
> of having the standards process contaminated by the interests of
> donors/ contributors.  If the standards body manages the
> sponsor, that advantage is lost, and all sorts of complications
> -- legal and of appearances-- immediately appear. But some of
> the proposals of Carl's document, especially Scenario C (and now
> D) and some of the "Mechanisms" of Scenario B, would put us
> precisely into a situation in which the standards body
> completely controls the "administrative" sponsor.
> 
> So I think we should back up a bit and concentrate on the
> critical path, rather than on constructing the edifices and
> monuments of complex structures that might actually weaken the
> IETF.  Once we understand that critical path, and how to solve
> the critical path problems, it may be sensible for us to return
> and look at other issues, ornamentation, etc.
> 
> While different of us have different definitions when we get to
> the fine details, I suggest that another way to identify the
> critical path is to ask ourselves, for each idea and proposal,
> "does this represent the solution to a problem that, if solved,
> will improve the IETF's ability to efficiently produce
> good-quality standards... and improve it enough to make the
> investment in, and risks of, the change worthwhile?".   If the
> answer is "no" then, IMO, we should get the issues for which the
> answer is "yes" dealt with first and return to the "no" cases
> later, if ever.   Put yet differently, if something is going to
> be expensive, disruptive, or risky to fix, then it had better be
> seriously enough broken to justify the work.  The two
> critical-path issues described above appear to meet that test.
> Nothing else that is now on the table as "administrative
> restructuring" seems to meet it.
> 
> Compared to other standards bodies, the IETF has some important
> distinguishing features.  For this discussion, the key ones are
> 
>   -- Little permanent bureaucracy, and
>   -- Minimal focus on process for its own sake
> 
> In addition,
>   -- We don't expect our senior volunteer leadership to
>      directly manage budgets or staff
> 
> While this is as key a feature as the other two, no other
> voluntary standards body has this expectation either.  The
> comments above about "sponsors" reflect the reasons what that is
> the case.
> 
> The scenarios Carl outlines, especially the more "independent"
> ones, appear to compromise all three.  3716 suggests one
> employee.  While it may not be obvious on casual reading,
> Carl's document recognizes the fact that, especially in an
> "independent" operation, the Administrator would need to be
> augmented by additional staff.  Whether that staff become
> employees of the IETF Administrative Entity, or are
> contractors, or are "leased" as part of some other arrangement,
> or are outsourced entirely, may impact appearances or budget
> pools -- and some options are more expensive than others-- but
> they still need to be managed and given direction.
> Exceptionally satisfactory performance needs to be rewarded and
> exceptionally unsatisfactory performance needs to be corrected
> or punished.  If that level of direction and management is not
> in place, then we reinvent critical-path problem (2) above,
> with an unfamiliar organizational structure, and that would be
> negative progress, IMO.
> 
> It is much more subjective, but these discussions seem to lead
> to much more process too, and all of the options in Carl's
> report seem to put the IETF Leadership, especially the IETF and
> IAB Chairs, squarely in the middle of it.  As I have pointed out
> elsewhere, we aren't selecting those people for business
> administration and budget skills, don't have a good model for
> doing so if we wanted to, and should not want to (Carl's -01
> draft makes this point as well, at least as I read it).  And, as
> discussed in some of my other notes and more briefly above, no
> other voluntary standards body puts its finances under the
> control of the volunteer standards leadership.  That separation
> is maintained for important substantive reasons, the most
> important of which is to avoid entangling the standards process
> in apparent conflicts of interest.
> 
> Of course this does not imply that the standards body and its
> leadership should be kept in ignorance of the administrative
> and financial arrangements, nor that they should be "protected"
> from having effective input into them.  Reporting and openness
> and discussions, whether about budget status or about bagels at
> meeting breaks, should obviously be permitted and, in general,
> encouraged.  But we should not confuse openness and reporting
> with decision-making authority.  Responsiveness should include
> consideration of fiscal and strategic administrative issues.
> And the guarantee of responsiveness, in _any_ organizational
> structure in which administrative/financial management are
> separated from standards management, lies in mutual trust and
> mutual understanding of goals and objectives, not in
> discussions of, e.g., who can blow whose bolts.  
> 
> The administrative structure needs, as an absolute requirement,
> to pay careful and high-priority attention to input from the
> standards structure because it is the only way the IETF can
> succeed.  The standards structure needs, as an absolute
> requirement, to pay careful and high-priority attention to
> input from the administrative structure because it is the only
> way the IETF can succeed.  If either body does not understand
> that, it is in need of radical restructuring or replacement.
> But building complex structures to prevent or react to events
> that are not only unlikely but also impossible to precisely map
> in
> advance is bad engineering and bad administrative planning.
> 
> Whether it has been fully appreciated by the community and its
> leadership or not, the above describes, not only a possible new
> regime, but how things have always been done in the IETF, at
> least when things were working well.  The standards leadership
> explained needs to the administrative/financial organization;
> that organization responded by either complying with those
> needs or engaging in a dialogue about what was feasible and
> what the alternatives were.  The problems we have seen more
> recently were not in the model, but that the "complying...
> engaging" part appears to have gotten lost somewhere along the
> line.  And while, IMO, there were particular factors that made
> that breakdown likely in the current case that would not apply
> to any of the plausible alternatives, there is some risk of
> getting into that state with _any_ separate administrative
> structure.  We need to understand that and accept it, accepting
> in particular that even a Nomcom-selected body that is subject
> to the recall rules can become unresponsive to the community.
> And, again, erecting idols of the bolt-blowing deity won't make
> it painless if is occurs, no matter how impressive the statues
> or how polished the mechanisms.
> 
> 
> The question, then, is whether we can devise a scenario that
> addresses the critical path questions without inventing any
> more administrative structure than needed, without depending on
> unreasonable expectations of the skills of the IETF _technical_
> leadership, and without compromising the apparent and actual
> independence and ability of the IETF to develop good technical
> standards without undue influence from funding sources.
> 
> Assuming that scenario is an appropriate goal and the one we
> want to address in this effort, I've reprised key criteria
> below. Obviously, there is a separate question of whether a
> Grand IETF Restructuring is a more appropriate goal and useful
> in and of itself.  My own view is that it is quite unlikely to
> be worth the risks and costs.  But, should the community really
> wish to go down that path, I urge that we consider it in terms
> of what problems are being solved and how important it is to
> solve them.
> 
> To reprise, the criteria for that alternative administrative
> organizational structure should include:
> 
> 	(i) The IETF volunteer (standards process) leadership and,
> 	for that matter, anyone with responsibility for steering
> 	the standards process, is at arms-length from financial
> 	dealings with particular donors who might be assumed to be
> 	influencing the IETF's standards process.
> 
> 	(ii) Nomcom appointments to IETF volunteer technical/
> 	standards process leadership positions are not expected to
> 	require that candidates have significant administrative
> 	or financial skills, nor are candidates expected to acquire
> 	those skills on appointment.
> 
> 	(iii) We put as much IETF energy into organization-creation
> 	as is actually needed to solve identifiable and real
> 	problems, and no more.  In particular, we don't try to
> 	create elaborate structures to handle hypothesized problems
> 	that have not occurred and probably will never occur, nor
> 	do we try to use IETF Administration as a way to develop
> 	and carry out unnecessary social experiments.
> 
>      john
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

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