[rfc-i] REOC membership
john+rfc at jck.com
Sat Jan 22 14:25:20 PST 2011
--On Saturday, January 22, 2011 11:47:47 -0800, Dave CROCKER
<dhc at dcrocker.net> wrote...
>> Since the IAB is the appeal body for REOC decisions, there is
>> already a built-in way to resolve severe conflict.
> The core flaw here is about efficiency and even competence of
> the process, where enough in-efficiency actually produces
> unworkable results.
Dave, we are largely in agreement, but I see a slightly
different model to accomplish most of the same things (and share
your distaste for appeals --or, worse, recalls-- as a presumed
> And note that we do not allow an AD to provide oversight for a
> working group in which they are active.
And I don't belive we have ever established that rule as a
matter of formal procedure in an RFC. It is just established
custom, established both by convention within the IESG and the
knowledge that the community would respond with some outrage if
an oversight relationship existed and any controversy occurred.
> In the case of the IAB, we have a sustained demonstration of
> minimal interest in the RFC Editor function. (That's not
> sour grapes from me; I am far from the only person to make
> this observation; others include sitting IAB members...)
And, to be explicit, I'm one of those who has made the
observation. I don't think there is any desire in the IAB to
keep it a secret. However, while we have not been as explicit
about it to the community as we probably should have been, one
of the changes in the IAB in the last couple of years has come
from the realization that the IAB is not all-knowing, competent
in all areas, and, as membership shifts, completely stable in
its collective interests (if it even can be said to have
collective interests). That situation is incompatible with the
IAB exercising _any_ long-term responsibilities if it has to
depend on its membership along: that minimal interest in the RFC
Editor Function is not unique, in actuality, the IAB becomes
more or less interested in a broad list of topics as its
membership shifts (and, of course, it has little control over
those shifts, a situation that the community formally considers
As discussed briefly in a plenary or three, the IAB's response
has been to start to move to more of a "Project" model in which
Projects are established and populated with a mix of IAB members
and others with responsibility to provide a stable focus on
topic areas, include a higher density of expertise than the
Nomcom-selected membership of the IAB might, etc. The IAB
maintains responsibility for what it and its Projects do but may
delegate greater or lesser amounts of authority to the Projects.
Now, in the case of the REOC, I see it as an IAB Project, with
participation/membership including selected IAB members, some
folks who can represent the particular focus of the streams, and
some who can represent a more strategic perspective and the
needs of the broader community. I see accountability running
from the RSE to the REOC to the IAB (with the IAB ultimately
accountable to the community, as always), and authority flowing
the other way on a flexible and dynamic basis.
I believe that, if we try to establish things more rigidly than
that, e.g., by specifying all of the relationship boundaries in
RFCs, we are almost certain to discover that we've gotten it
wrong and created rules we then need to work around or ignore
...as the community's talents with organizational models and
relationships have demonstrated over and over again. Instead,
we should try to assume that people will do the right thing and
that, if they don't, it will be in some way that we haven't
predicted well in whatever scenarios we have worked out.
> More generally, it's a poor design that builds in significant
> flaws. (duh.)
Indeed. And a poor design that concentrates on the possible
failure modes that are obvious to us (and therefore unlikely to
occur) and that ignores that ones that we don't anticipate. I
believe the IETF has made that mistake repeatedly.
> There are times when "conflict of interest" is a silly rule to
> apply and in fact one should guard against it by welcoming
> lots of it. That produces competing interests and if they
> can agree, everything is fine.
> This however is a very bad idea for a tight, small oversight
> group that is expected to have intimate involvement in
> strategic work.
> A group like that needs to be reasonably detached from
> immediate special interests. Each member needs to be able to
> give fair weight across a topic, rather than being so
> enmeshed in one perspective they can't get broad perspective.
> So, a group like the REOC needs members who are not actively
> involved in other parts of the RFC Editor management structure.
I agree. And, under perfect circumstances, I'd prefer to keep
any explicit representation of the streams out of the REOC, not
only because those interests will be adequately represented in
other ways but because I believe that the experience of having
the streams (especially the IETF Stream), previously under other
names, constitute the management committee for the RFC Editor
has been one of the things that has retarded innovation and
caused an attitude of "the only productivity and effectiveness
measure is the output page count". But I don't see a few
stream-appointed representatives on the REOC as being a
> ps. As for the fact that we already have some
> "cross-pollination" in existing management groups, I'll
> suggest that rather than treat that as precedent we should
> treat it as poor design. (And please, folks, do remember that
> none of this is personal; everyone involved is
> well-intentioned, expert, etc., etc.) And by the way, it also
> makes some of these positions difficult to fill, because they
> consume so much time..
Well, I agree. But the evidence is that the community does not.
As an example, efforts to separate the IAOC roles from the
Trustee ones and to make the IESG and IAB representatives to the
IAOC and Trustees the decision of the IESG and IAB,
respectively, rather than wiring in the Chairs have gotten
absolutely no traction.
More information about the rfc-interest