I-D ACTION:draft-ietf-problem-process-00.txt
Brian E Carpenter
brian at hursley.ibm.com
Sun May 18 17:36:53 CEST 2003
below...
Eric Rosen wrote:
>
> > 5.1 Near-Term Improvements
> ...
> > 5. Modify IESG-internal processes to make it impossible for one
> > or two IESG members to block a document.
>
> Brian> There is a strong implication here that ADs might do this for
> Brian> spurious reasons.
>
> Well, yes, that's the "problem".
>
> Brian> But if one or both Security ADs are deeply
> Brian> convinced that a draft constitutes a major security risk, or one
> Brian> or both Routing ADs are convinced that a draft will lead to routing
> Brian> loops, isn't it quite appropriate for them to block the document?
> Brian> Such cases suggest failures much earlier in the process, not
> Brian> misbehaviour by the IESG. So I don't think we should fix this,
> Brian> because it is actually a vital back-stop, not a bug.
>
> You can't remove a problem by declaring it not to be a problem; that's
> called a "whitewash". And the fact that the ADs sometimes act properly
> doesn't mean that they don't sometimes act improperly.
>
> The problem is that there is no effective and open process by which such
> decisions can be reviewed and evaluated to determine whether they are proper
> or improper.
This generated its own sub-thread, but I want to say here that Eric's
response clearly indicates that point 5. quoted above is *not* the actual
issue. The actual issue is
5. Modify IESG-internal processes to make reasons for the IESG's
blocking of a document visible to the public.
Brian
More information about the Problem-statement
mailing list