"Spencer" == Spencer Dawkins <spencer(_at_)mcsr-labs(_dot_)org> writes:
Spencer> - It is probably helpful to include a reference to a
Spencer> - One point I took away from the recent chat about IANA
Spencer> registration on this list is that a substantial portion
Spencer> of the community thinks that when the IESG speaks, the
Spencer> IESG has spoken.
Spencer> I understand that the term "discuss" is chosen
Spencer> intentionally (there is no "how long have you been
Spencer> smoking crack?" ballot option), and believe that the IESG
Spencer> actually expects the authors/editors/working group
Spencer> chairs/working group to "discuss" the draft with the
Spencer> AD/IESG, but I believe that a significant portion of the
Spencer> community hears "discuss", they think the IESG means
Spencer> "Discuss" (capitalized for emphasis), or maybe even
Spencer> "DISCUSS" (the IESG equivalent of a bullet through the
Spencer> forehead), and they start randomly changing text or
Spencer> otherwise folding up like cheap furniture, instead of
Spencer> expressing what the working group was trying to do in the
Spencer> DISCUSSed text.
YES! It's very frustrating to me when I ask a blocking question and
get a note saying that "the new draft addresses your discuss." I have
to figure out what changed and then try to imply an answer to my
question. I'd much rather have a dialogue.
Spencer> I would suggest one paragraph that says something like
Spencer> "when we say "discuss", we mean this in the common
Spencer> English sense, even if we spell it in all caps, and we
Spencer> really do want a dialog, not random changes to a
Spencer> specification in the hopes of placating us and getting
Spencer> the DISCUSS removed".
Yes.
Spencer> This would naturally fit at the beginning of Section 4
Spencer> failure.
Spencer> - I'm not sure I "get" 3.3 ("saying no to a document"),
Spencer> for these reasons:
Section 3.3 is mostly my fault so I'll try and defend it.
The fact is that there is some possibility an AD will want to try and
convince the IESG that a document is so bad it should not be
published. If we don't clearly document suggestions on how to do
this, a lot of bad things will happen. First, in the middle of trying
to deal with a specific document we'll be debating what procedures to
use. People will be more upset about the process issues than the
actual technical issues. Things will take a lot of time and they will
not be efficient. Instead, what I'd like to do is have suggestions
written down ahead of time on how to behave so that we can quickly
determine how the IESG as a whole feels about the document. If more
than 4 ADs don't want to see the document go forward, then clearly we
need to spend some significant time on it. (passing a document
requires 9 ADs on the current IESG). If only 1 person feels the
document should be stopped and the other ADs have already carefully
considered the issue, well, we run on rough consensus.
Spencer> (1) If the irritated AD votes "abstain", the document
Spencer> doesn't say what the resolution path is - is the idea
Spencer> that some other AD who didn't write the comments reads
Spencer> them and votes "DISCUSS - Marvin's comments are right, or
Spencer> you need to explain why they are not right"? Or is an
Spencer> ABSTAIN with very irritated comments somehow a special
Spencer> state?
Generally it's a special state: you are mostly admitting that you are
part of the rough rather than the consensus and you expect the
document to go forward despite your objections. The only case this is
not true is when too many people vote abstain.
Spencer> (2) The ABSTAIN path (assuming that (1) is explained
Spencer> fully) seems entirely sufficient, without adding the
Spencer> "However" path, where the irritated AD writes the
Spencer> comments and still votes DISCUSS. How strongly does the
Spencer> IESG feel about this? To me, it is edging toward "IESG as
Spencer> protector of the universe", but it assumes that the AD
Spencer> can't convince anyone else to vote DISCUSS (or whatever
Spencer> the path through (1) is). The DISCUSS path seems like the
Spencer> weakest part of this very good 00 draft. But maybe I just
Spencer> don't understand the path through (1) well enough to
Spencer> understand the difference between the ABSTAIN option and
Spencer> the DISCUSS option.
So, I at least feel really strongly about the discuss path. The
problem with the abstain path is that part of forming consensus is
taking the time to understand the people you disagree with.
I want the opportunity to stop the document for a week or so--possibly
a bit longer--to try and explain to others why it is broken.
Practically speaking the way to do that on our ballots is a discuss.
I should only use this discuss to get an opportunity to explain my
position and to work with people to make up their minds. I should do
something else with my discuss as soon as any of the following are
true: the discussion is not making progress, everyone understands me
and has made up their mind, or too much time has passed. I don't
think specific time limits should apply, but I think the chair of the
IESG should be very sensitive to claims from the document authors and
the proponents of the document on the IESG that the discussion has
dragged on too long.
If I had started with an abstain, I would not have been given this
opportunity. People would probably read my abstain comments, but in
general abstain comments do not even get discussion in the telechat.
Once the discussion is done, I can do one of two things. In most
cases I'll want to change my vote to an abstain. The outcome is
probably reasonably clear and I'll either have convinced enough people
or not.
However another thing I could do is insist on an override vote. The
reason I would do that is that an override vote has different voting
criteria than a normal vote. It takes 5 ADs to say no to a document
on a normal vote and 3 on an override vote. I don't think it would be
wrong to use the override mechanism provided that you did it quickly
and did not use it as a delaying tactic.
Spencer> (3) The description of the ABSTAIN path says "writes up
Spencer> the comments", and the description of the DISCUSS path
Spencer> says "explain his or her position as clearly as possible
Spencer> in the tracker". Is this really different, or just the
Spencer> kind of thing that happens the week before the 00 cutoff?
Text written by different authors.
Spencer> (I know it happens in MY 00 drafts!) I still wish there
Spencer> was some reference to the comments on this evil, evil
Spencer> draft actually appearing in the mailing list that is
Spencer> theoretically the archive for discussions about the
Spencer> specifications produced by the working group, but let's
Spencer> let that lie for now.
I'm not sure this draft is the right place for that discussion but I
completely agree with you.
Spencer> - The first paragraph in Section 4 is more specific than
Spencer> "the people who need to discuss the draft, discuss the
Spencer> draft", but not a lot more specific. I understand that
Spencer> many possible combinations of AD/ADs/IESG and
Spencer> editor(s)/working group chair(s)/working groups may end
Spencer> up as parties to the discussion, but I would like to see
Spencer> text that finally assigns responsibility for negotiating
Spencer> DISCUSS resolution to SOMEbody (not sure I care who). If
Spencer> there was a sentence that says "DISCUSSes are supposed to
Spencer> be serious and relatively rare, so DISCUSS resolutions
Spencer> should be posted to the appropriate mailing lists before
Spencer> the document appears on the next IESG telechat agenda",
Spencer> that would be lovely. Other sentences with other nouns
Spencer> might be lovely as well.
The proto shepherd (or document shepherd for non-proto documents) is
responsible for making sure progress happens on resolving discussions.
I'd assume that you would complain to the document shepherd and/or
IESG chair if the process is failing.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf