[rfc-i] RSOC oversight role
stpeter at stpeter.im
Wed Feb 16 12:52:47 PST 2011
+1 to what Andrew said.
But he forgot Category 0 -- people who are so involved all over the
place that they can't keep up with this list. :)
On 2/16/11 1:46 PM, Andrew Sullivan wrote:
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
More information about the rfc-interest