what is a problem
Thomas Narten
narten@us.ibm.com
Mon, 25 Nov 2002 14:36:44 -0500
> Note: if you haven't already, be sure to look at the ID tracker state
> machine documentation. It is a pretty good summary of our internal
> processes with regards to documents.
> https://datatracker.ietf.org/state_diagram.gif
> https://datatracker.ietf.org/public/states_table.cgi
One more (non-url) piece of information. If you are in ID tracker, and
go to a specific document for which there are IESG comments, there are
clickable links that describe how we record Evaluations. I'm including
the description here for easy access, as they further describe
internal IESG process.
Explanation of Discusses
The process that the IESG uses for recording and documenting issues
with documents is called an Evaluation. Evaluations provide a
mechanism for ensuring that each AD has the opportunity to review each
document and to keep track of who has (and has not) yet completed an
evaluation for a particular document.
The procedure for all normal evaluations is this:
- "Yes" means "I read it, I think it's good stuff, make it so."
- "No Objection" means "I would not object if this document went
forward".
Examples where No Objection might be used include:
- I read it & have no problem with it
- I read the protocol action & trust the AD so have no problem
- I listened to the discussion and have no problem
- "Discuss" means "I cannot in good conscience send this document
forward, but if it were fixed in these ways, I would change my
Evaluation to 'yes' or 'no objection'", or it may literally mean
"I think we need to talk about this."
These comments must be written at the time that the "discuss" is
placed, either in the email presenting the "discuss", or in a
follow-up note. Discuss comments are recorded in an Evaluation for
tracking purposes.
This should not be an open-ended discussion. If we have a
significant problem with the protocol, we should return the
document to the working group or author for resolution of the
problem. "Discuss" should be used when there are technical
difficulties that can be articulated and are major enough to
require that the document be revised prior to approval. If an AD
cannot get cooperation from the community and cannot agree to send
a document forward, he or she should "abstain".
- "Abstain" means "I cannot support sending this document forward,
but I will not prevent the rest of the IESG from doing so."
There are two obvious reasons one might select "Abstain":
- so strongly opposed to document that I am unwilling to "discuss".
(note that this should be very unusual)
- I oppose this document for some philosophical reason but
understand that others differ and am not going to stand
in the way of the others
- "Recuse" means I have a conflict-of-interest and am not
participating (e.g., I am document editor, WG Co-chair, etc.).
- "Defer" - give me a stated amount of time - one telechat cycle, two
with the consent of the chair - to read the document. Other discussion
may and presumably will continue, but no decision will be reached until
the agreed time has elapsed or the requesters have all changed their
Evaluations, whichever happens earlier.
It takes at least one "yes" from an AD from the relevant area, and a
total of 2/3 (excluding recuses) of the IESG indicating "yes" or "no
objection", and no "discuss" Evaluations to move a document.
Alternative procedure, invoked by the chair in the event that the IESG
deadlocks (discussed several times but has never actually been used)
- all ADs must read the document by a time stated.
- the Evaluations are up-down -
"yes" means "I read it and it is good stuff"
"no" means "I read it and it is not good stuff"
"abstain" means "I read it but I do not feel qualified to comment"
In this case, 2/3 of the IESG must say "yes" and not more than two ADs
may say "no". Continued deadlock sends it back to the working group.