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