I-D ACTION:draft-ietf-problem-process-00.txt

Dave Crocker dhc at dcrocker.net
Fri May 16 18:13:42 CEST 2003


Brian,

>>          5. Modify IESG-internal processes to make it impossible for one
>>             or two IESG members to block a document.
BEC> There is a strong implication here that ADs might do this for
BEC> spurious reasons.

At base, the reasons do not matter.  It simply is not reasonable for any
one (or two) people to weild that much power.  A group based on Rough
Consensus should rely on those having a point of view being able to
recruit others to support that view.  If they cannot succeed in their
recruitment effort, there is something wrong with their view.

We believe in technical expertise, not technical deities.

Expertise is compelling, when the expertise is real. Only deities
warrant individual veto authority in this community.

BEC> But if one or both Security ADs are deeply
BEC> convinced that a draft constitutes a major security risk, or one
BEC> or both Routing ADs are convinced that a draft will lead to routing
BEC> loops, isn't it quite appropriate for them to block the document?

If they cannot convince others of the correctness in their views, then
no.  The failure to make a compelling case strongly suggests that the
case is itself problematic.



BEC> A very important step is missing here. All IETF process documents need
BEC> to be formally accepted by the ISOC Board, to ensure that we have the
BEC> necessary chain of authority to validate the liability insurance.

Thanks for catching this.



>>  5.2.2.2 ISOC-Directed Approach
>> 
>>     Another approach would be to ask the ISOC President and the ISOC
>>     Board of Trustees (ISOC BoT) to assume responsibility for the
>>     oversight of the IETF Improvement WG, similar to our current
>>     Nominations Committee processes, as defined in RFC 2727 [RFC2727].
>> 
BEC> Although I am currently an ISOC Trustee, I certainly can't speak for
BEC> the ISOC on this. However, I wouldn't advocate it. Only a few members
BEC> of the ISOC Board are truly familiar with the IETF's internal workings.
BEC> Having the Board accept the final documents, as noted above, is enough.

The idea is to model the process after the ISOC portion of the Nomcom
process.


d/
--
 Dave Crocker <mailto:dcrocker at brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>



More information about the Problem-statement mailing list