Subject: Re: When to DISCUSS?

From: [email-masked] (Scott Bradner)
Date: Fri, 8 Jul 2005 07:57:33 -0400 (EDT)

re draft-iesg-discuss-criteria-00.txt

I think this is a very helpful document - if followed by the IESG it
should reduce the number of what appears to be blocking actions
by ADs 

but I did not see any enforcement mechanism - i.e. if an AD enters a 
DISCUSS over a section 3.2 reason how does the IESG tell that AD
to back off?  It seems like the alternate voting process is
not needed to have the IESG look at a DISCUSS comments and reach
a consensus that it is not (or is) a legit DISCUSS area

maybe somthing like a 'review of comment' process that gets 
kicked off by another AD or a WG chair after an AD files their
DISCUSS comment.  The process just involving a requirement for all
ADs to review the comment in question and discuss the issue on
the next IESG call ending in a vote - if there is not majority 
support that the comment is a blocking type then the DISCUSS is
changed to a non-blocking comment

Scott

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Sun, 10 Jul 2005 20:46:38 -0400

>>>>> "Scott" == Scott Bradner <[email-masked]> writes:

    Scott> re draft-iesg-discuss-criteria-00.txt

    Scott> I think this is a very helpful document - if followed by
    Scott> the IESG it should reduce the number of what appears to be
    Scott> blocking actions by ADs

    Scott> but I did not see any enforcement mechanism - i.e. if an AD
    Scott> enters a DISCUSS over a section 3.2 reason how does the
    Scott> IESG tell that AD to back off?  It seems like the alternate
    Scott> voting process is not needed to have the IESG look at a
    Scott> DISCUSS comments and reach a consensus that it is not (or
    Scott> is) a legit DISCUSS area

how about just waiting to see if we have a problem before designing
new process?

It seems likely that if there is internal conflict within the IESG,
the IESG will find a way to resolve that conflict.  If you don't feel
that you can leave these sorts of details to the IESG, then you
shouldn't be trusting the IESG at all.  That's a valid position, but
it is not resolved by creating enforcement mechanisms.

--Sam

---

From: [email-masked] (Scott Bradner)
Date: Sun, 10 Jul 2005 20:57:19 -0400 (EDT)

> how about just waiting to see if we have a problem before designing

we have running code that there have been problems in the past 
maybe this new process will help avoid some of them & maybe the IESG will 
be more ready to push back on ADs that do not follow these much clearer
guidelines - I hope so

> it is not resolved by creating enforcement mechanisms.

humm - I thought this was a document from the IESG not someone
from outside trying to impose process on the IESG so I'm not
sure if a resolurtion process shoudl be called an "enforcement
mechanism"

in any case I do hope that the IESG will think about what to do before its
confronted with a specific case even if its not willing to give the 
public any hints

Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jul 2005 15:32:52 +0200

> it is not resolved by creating enforcement mechanisms.

In the end a lot of this comes down to judgement calls, and these
guidelines help to set expectations for those calls. If someone
sends in a DISCUSS and gets back "Really?" from a couple of other ADs,
the judgement may rapidly swing the other way. I'd say the IESG is
trying quite hard these days to clear DISCUSS ballots quickly if
possible, and there are quite a few that vanish before or during the
telechat.

Also, by putting these guidelines into public view, we will hopefully
get community feedback on marginal DISCUSSes, since they are visible
in the tracker.

     Brian

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 12 Jul 2005 03:22:34 +0900

> get community feedback on marginal DISCUSSes, since they are visible

Given that IETF is poorly operated these days, guidelines or
interpretations by management entities on the guidelines must
be wrong.

So, there is no point arguing that the current guidelines and
the current interpretations on them are good enough.

Either (or both) the guidelines defined by the current process
or the management entities chosen through the current process
are wrong.

						Masataka Ohta