Four observations on the plenary discussion of my drafts...
As I said at the end, I had not planned to come to the
microphone at all. I wanted to listen. What I heard
included...
(1) To repeat what I did say (since it was apparently hard to
hear) I see, once again, the problem that it has become
very hard to introduce a concept into this community. If one
tries to do so via a comment on a mailing list, there is never
enough detail for anyone to really evaluate it (or the message
is so long that almost no one reads it). If the concept is
presented in an I-D, then the document is torn to shreds for
not having enough detail for anyone to evaluate it. On the
other hand, if details are provided in the initial document,
even as an example to show that a plausible set of details is
possible, the community (often including especially the IESG,
immediately focuses in on the details and picks at them,
ignoring the general concept and the usually-better question of
how to adjust the concept and fill in any blanks.
This behavior has a corollary along the "we cannot handle
complexity" dimension. If one writes a single draft that covers
the several aspects of a problem, it is attacked as "too long,
too complex, and covering too many issues" and told it should be
broken up into smaller pieces. If it is broken up (the set of
issues here are now two and I have been advised to produce a
third that identifies the principles only), then people complain
that having several drafts at once is too much to deal with.
That way of handling things, especially things that some people
apparently just do not want to deal with, applies, I think, to
both process proposals and our technical work. It is not good
news if we actually want to get things done.
(2) Several comments, during and after the discussion and most
precisely framed by Spencer Dawkins, that I may have made an
incorrect assumption about transition. The text more or less
assumes that the review panel membership would be new
and the IESG membership would be left in place. Perhaps the
current IESG membership are most skilled in document review
rather than the sort of WG leadership and steering functions
that I had in mind -- the functions I think we had in the
early 1990s. If that were the case, then we should resolve the
detail of the IESG being larger than the review panel, shift
the current IESG members onto the review panel, and repopulate
the steering/coordination/management entity (probably calling it
something other than "IESG").
(3) A comment from an IESG member that the notion would probably
add work, since the document provides for documents rejected by
the review panel to cycle back through the IESG. To me, this is
one of the "sample detail" issues identified above. If the IESG
wants to be explicitly in that loop, and the community wants
that, then "back to the IESG as the submitting body" is the
right model. I had anticipated their involvement at that point
as lightweight, with the AD reviewing the comments and passing
them on to the WG, but not assuming today's role of negotiator
with the WG (or between the WG and the review panel). I think
that negotiator role, after a document goes out for IETF Last
Call, is the source of several of our problems and needs to be
eliminated.
For those who are reading this without having read the document,
please note that rejection of a document by the review panel is
intended to be A Big Deal. The document suggests a process that
would focus on getting good-quality, pre-reviewed, documents to
the review panel --with shared responsibility between the WG and
the IESG's steering/managing function for being sure that
happens-- with the review panel only organizing a final check.
If the IESG believes that being in the "return" loop would be
burdensome, then the proposal can easily be adapted to that
belief. The change would be to have the review panel return the
document directly to the WG, with the AD involved only as part
of WG management. The IESG would then be involved again only as
part of routine WG oversight and when the WG concluded that it
was ready to resubmit the document. I will make that change for
-01 unless others object.
As a particularly strong variation, one could have the review
panel return the document to the WG and then require either a
"new benchmarks" or recharter activity since "rework a rejected
document" would not be on the WG's pre-rejection charter.
Again, from my point of view, these are details that can be
sorted out and tuned if the community likes and wants the
general concept. If the community does not, there is no point
wasting the time to generate and debate those details.
(4) I heard at least one IESG member say something that sounded
suspiciously like:
"We are really busy and have all of these technical
documents to review. If you really want to discuss changes
and process proposals, we will be happy to defer action on
all of your technical documents until you come up with a
process proposal that we like".
I'm sure that was not intended. However, some reassurance
would be appropriate. It would also, IMO, be appropriate to
pay careful attention to comments (last night and earlier) that
it is probably time to come up with a process for reviewing and
approving process proposals that does not involve the IESG
other than as community members who can comment on a proposal
along with the rest of us.
Almost as a side-effect of the core changes, the review panel
proposal suggests moving sign-off on process proposals to the
IAB. Would it be useful to generate a very short I-D that does
that, and that only, as a means of moving things forward?
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf