My point was this: if a WG actually missed anything substantial and
that comes out during an IETF last call, and the shepherding AD
agrees, the document gets sent back to the WG. If the shepherding AD
also misses or misjudges, any member of the IESG can send it back to
the WG for resolution. What I think is not acceptable is for the
author and one or more DISCUSS ADs to hack up the document and publish it.
I think it would be useful to separate this discussion into different parts:
- what issues can be raised as a Discuss
- balancing the IETF opinion vs. WG opinion when there is a conflict
- how text proposals and draft revisions get created
- the role of shepherds, authors, and sponsors during this process
- how WGs become involved in changes from IETF Last Call and IESG reviews
The Discuss criteria document says quite a bit of the first topic.
Earlier in this thread we talked about the second topic.
But I wanted to say a few words about changing text to resolve an issue.
I said earlier that I would rather not be sending text proposals. I
didn't want to imply that text coming from the IESG would be
inappropriate. And certainly text coming from the author would not be
inappropriate either. In fact, it is quite typical that the Discussing
AD, possible directorate experts (if involved), and the author are the
most likely suspects to come up with a way to resolve an issue. And most
motived to get to a resolution. For instance, some of my documents have
recently had issues with PMTU, and I asked the Discussing transport ADs
to work with the authors to design a solution; this worked well. In
this sense "hacking the document" is not just OK but it may actually be
the right thing.
The problems with the Discussing AD proposing text are more in the area
of scalability. I prefer seeing the authors (or shepherds) be active and
propose ways to resolve an issue. Or at least the initial proposal,
review and suggestions from both sides may be needed to converge.
The big problem with any of the key players (author, Discussing AD,
sponsoring AD) making changes relates mostly to the fifth item on my
list. We are not very good at keeping the WGs in the loop. This is often
done right, but far from always. I know I have problems in this area.
One of the consequences is less control on the WG's side on
controversial topics. Another one is reduced review of new text; errors
might creep in. While the hacking part may have been OK, the publication
is the problem.
I don't want to make excuses, but it may be helpful to understand some
of the reasons behind this:
- Some issues are too small or obvious to warrant engaging the WG;
getting the document approved on the given telechat day is seen as a
higher priority. A fairly large number of Discusses get resolved on the
day of the telechat, having been filed just days or hours before.
- The author - AD team works at a much faster pace in many cases than,
say, the shepherd or the entire WG.
- Discussing AD is not on the WG list, does not know status of the
document in other respects than his or hers own Discuss.
- Things falling in the cracks, e.g., Discussing AD thinks that the
shepherd or the sponsoring AD is responsible for talking to the WG.
- No guidelines or processes relating to how the WG is actually involved
in the discussion. In some cases we inform the WG what the Discusses are
and what is being done about them. In other cases we actually run
something resembling a WGLC or a consensus call. In yet other cases the
new draft version announcement goes to the list as the sole
announcement, and people are expected to look at the tracker for the
- Desire to avoid lengthy discussions.
- Sponsoring AD trusts that the Discussing AD and author have made the
- WGs that for some reason have stopped caring about anything else than
getting the document published. Not care about the particular hoop that
they have to jump through to resolve a Discuss. (And by the same token,
not care about Comment level review issues at all).
Some of these issues could be improved with a clearer definition of
roles, and some additional guidelines on how to involve the WG.
Ietf mailing list