On 11/8/19 4:49 AM, Ole Troan wrote:
I have for a long time been uncomfortable with the level of document changes that happens after the document leaves the working group.
From my perspective I would have preferred a document process, where the working group "owned" the document until publication.
For cross-area issues:
The responsible AD together with the chairs should identify cross-area conflicts and need for collboration earlier in the process. And as chairs/responsible ADs escalate cross area issues, those should be discussed in the IESG while document is in the working group.
That's too few people, IMO. Also there's a tendency to call them
"cross-area issues" but I think that can be misleading. What I have seen
time and time again was that a WG or document author would make
decisions that would, for example, harm the ability of the Internet to
support a certain kind of application. But even a typical Applications
AD wouldn't necessarily realize that, because "applications" is
tremendously broad. (These days the ART area is even broader.)
I see no substitute for a community-wide review. A message is sent to
an appropriate list (maybe lastcall, maybe not) that summarize the WG's
charter and list each of the documents being worked on and describes how
they fit into that charter. The message states that the chairs and
IESG are interested in knowing whether these solutions harm other
interests, and more generally solicit community feedback on the approach
(keeping in mind that Z1 and Z2 are probably not finished yet), and
there's a special email address for the feedback that must be used.
Either make those solicitations for review explicitly part of a WG's
schedule, or automatically trigger them at one year intervals after a
group has started. The WG chairs would have the responsibility of
writing those descriptions, any responses would be recorded and made
publicly available, the WG chair would summarize the responses for the
IESG, and the WG is expected to respond to substantive feedback.
If a document isn't good enough, the IESG should send it back to the working group. Not try to "fix" it themselves (often in a small group between chairs, authors and ADs).
Agree with the latter part. IESG is in a poor position to "fix" a
document, especially so late in the process, though the same is true of
a WG that has labored years to produce something before even being aware
of potential harm that they're doing. That's why the reviews need to
be done well before a group thinks the document is complete.
Basically I want the IESG for leadership. I want the IESG for quality control. I do not want the IESG to have to read every document, nitpick or even (gasp) override working group consensus.
Mostly agree, though I don't see how the IESG can provide meaningful
quality control without each AD at least skimming the documents that are
relevant to that AD's area. But I have always thought that the IESG
and other reviewers should point out the problems and the WG should
figure out how to fix them. But they need that feedback as early as
possible so they can take that input into account when making their
compromises. "Last Call" and IESG review should be stopgap measures,
not the only means by which a WG gets feedback from other parties. Most
of the time final IESG review should be more of a process review than a
technical review. But part of that process review should consider how
the document addressed external feedback.
Keith
