what is a problem

[Thomas Narten]

presnick@qualcomm.com (Pete Resnick) writes:

> A while back, I had a document "stuck" in IESG review for what I 
> thought was a long period of time. It was (apparently) due to one AD 
> who had a concern with the document and I couldn't find out the 
> specifics of the problem.

Note: this is not supposed to happen (but I'm not saying it never
has). When a document is under full IESG review, issues with documents
need to written up and communicated back to the authors/WG. Our
internal policies have required this for some time, as formalized by
IESG "Evaluations".

> Now, let's imagine the current IESG process 
> is "If an AD wants to hold up publication of a document, they have to 
> provide the shepherding AD with a detailed explanation of the problem 
> to convey back to the document editor." If that were the case, then 
> the problem might be particular ADs not following the procedures of 
> the IESG.

The above is what is supposed to happen (and does mostly). But there
have certainly been times in the past when the ball got dropped during
this step. One can blame the AD who has the issue for not writing it
up, and/or the shepherding AD for not doing enough nagging to get the
comments out, or the shepherding AD for not taking the comments and
actually delivering them back to the authors. All have happened at
times.

Note that ID tracker will certainly help avoid this sort of
problem. Personally, it's now very easy for me to see which documents
(of the ones I'm shepherding) are in the "IESG Evaluation" state,
and/or those that are waiting for discuss comments to be written up
and so on.

> We can all think of solutions to that problem. However, let's
> instead imagine that the current process is "If an AD wants to hold
> up publication of a document, they may ask the IESG to 'discuss' the
> document, and that can go on ad infinitum." If that were the case,
> then the problem might be that the IESG process allows documents to
> languish on the say-so of only one AD. That's a different problem
> with a much different set of solutions.

IESG internal policies (i.e., running code) do not allow an AD to have
a vague "I don't like this" type of discuss. There is a little give
and take here, of course. The AD with the issue needs to describe an
issue sufficiently so that it can be taken back to a WG/author. But
the Shepherding may also want to push back and say "I don't understand
this", or "this is too vague", etc. But this back-and-forth is not
open ended.

It is also the case that when a document goes to the full IESG, we
discuss it at the next telechat. During the telechat, all issues are
supposed to get flushed out, modulo the "defer" (for more time). But
even a defer is a one-time event.

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

Thomas