[rfc-i] RSOC oversight role

Andrew Sullivan ajs at shinkuro.com
Wed Feb 16 12:46:07 PST 2011

On Wed, Feb 16, 2011 at 12:19:20PM -0800, Dave CROCKER wrote:
> Again:  If we are in such dire straights that an RSOC must be involved in 
> the details of the work, we have much bigger resource problems.  For one 
> things, it is a demonstration of an inability to delegate.

And as I said before, we do indeed have those resource problems.
That's not a problem of inability to delegate.  It's a problem of
inability to attract more people, partly because we have a lot of
arcane rules (written down in _RFCs_, for crying out loud, where
people can't even find the details of how their protocol ought to work
never mind how human interactions are supposed to work), partly
because anyone who hasn't been around here for over 10 years and
foolishly allows himself to be drawn into this kind of discussion
instantly regrets it, and partly because people are now either
well-funded to participate in the IETF, are doing it because they are
personally devoted to it and willing to spend that money (or,
equivalently, give up that income), or else are barely funded to
participate and therefore have to concentrate where they can.
Category 1 people are involved all over the place, Category 2 people
are hard to classify, and Category 3 people will not participate in
this kind of stuff: it's overhead.  Most actual IETF participants, I
claim, are in Category 3.  Most of the people in this discussion (and
who show up at the mics at IETF meetings, especially in the plenaries)
appear to me not to be.  Waving that away as an unimportant problem
does not help.

I don't get why this particular issue has to be called out as a
special case of conflict of interest.  That suggests some conflicts
are more conflicty than others.  What about other obvious cases?
Should someone on the RSOC be part of an organization that also
sometimes pays the RSE?  What about being someone who sometimes hires
directly the RSE?  What about participating in a contentious
discussion involving the RSE and a sticky issue about a protocol suite
where the RSE's employer happens to have IPR claims?  How about the
situation where the conflict involves a spouse or child who
participated in the relevant policy making body?  A close buddy who
was the other author of an early RFC and with whom one still
collaborates?  Do we need to list all these too?

I say no.  If anything, we should note that RSOC members might be
involved in other activities impinging on their responsibility of
oversight, and that they should be careful to recuse themselves in
case of a conflict of interest.  IMO, that's all any of this should
say (though I would have thought it went without saying).  If we can't
write good general guidance and trust the rest to sane, responsible,
highly-regarded members of the community to work out to the best of
their ability, then we have a much bigger problem, and we shouldn't be
drafting any of this.  We should set up a paid executive team, a
corporate structure, and a legal department, and let them do it.  (Or,
maybe, just give up and let $GIANT_BUREAUCRACY_OF_CHOICE do this

We have elected not to do that because we think our kind of community
based (dis)organization is important enough that working things out
mostly case by case is better, and that trusting intelligent people of
good judgement to use that judgement is a good idea.  Sometimes it
fails, of course.  But as I already said somewhere upthread, hard
cases make bad law.  We shouldn't be trying to craft rules to prevent
certain cases that today seem very bad, because the nefarious will
work around it, the clueless will blunder through anyway, and the
hapless will end up tied by a regulation that nobody intended to cover
the case in question.

> The rule should be simple and straightforward to say, think about and 
> apply. This is not a topic that needs anything careful and precise 
> because its application won't support it.

Then "don't be a jerk: declare your conflicts" oughta be good enough,
I think.


Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.

More information about the rfc-interest mailing list