[rfc-i] RSOC oversight role

Peter Saint-Andre 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
> stuff.)
> 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.
> A

Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20110216/050b8b80/attachment-0001.p7s>

More information about the rfc-interest mailing list