Re: I-D ACTION:draft-iesg-hardie-outline-00.txt

[hardie@qualcomm.com]

Hi Brian,
	Thanks again for your review; some replies and clarifications
in line.

At 11:44 AM +0100 10/29/2003, Brian E Carpenter wrote:
>Hi,
>
>My comments... some repeating what I had to say about the earlier draft.
>
>1. I think Area Boards are an excellent idea. But I am very unsure whether we should
>still have Directorates when the Area Boards are in place. I would encourage ADs
>to put ad hoc advisory committees in place if a topic isn't suitable for the Area
>Board, but having standing Directorates as well seems like too much bureaucracy to
>me.

I have personally seen the Directorates as likely to fade away after the
area boards are in place, but useful to have in the transition.  As it
stands now, some of the "mib doctor" type area directorates have been very
useful in speeding the review of documents; my problem with them has
been that they are ad hoc and focused on advising the ADs, rather than taking
independent action on a set of tasks.  I think we may want to leave open the possibility
of groups of people advising an AD, but I agree that it should probably be less
common and less important as time goes on.  In any event, it must narrow in
scope if we narrow the work of the ADs.


>2. I still think you are over-specifying the types of groups. I don't think we need
>these rigid categories. What we need perhaps is a set of charter templates, matching
>the types of group you have in mind - but let's keep the necessary flexibility.

Part of the aim was to distribute the load of chartering and managing working groups
to different management groups, as in the IAB management of the Investigative groups.  To do
that, I think we need at least some broad categories to match to the chartering
group.  I agree, though, that we will need flexibility here, especially because the
same group of people may be in a specification phase of one piece of work and
an investigative phase for another--as several folks have pointed out, this document
would require them to run two groups, which doesn't make sense.  I'd love to
have your thinking on how to resolve this.


>3. I don't understand the "IESG teams" concept. Does this refer to strict sub-teams
>of the IESG? If so, I don't see any delegation of workload (today, anyone who votes
>no-ob is essentially equivalent to someone not in the team). Are the teams the ADs
>concerned plus some external people? This isn't clear in the text, but it's the only
>way I can see that gets work off the IESG plate.

The idea is to shift from a model where the sign off is per AD to a model where
the sign off is per Area, so that the workload of final cross-area review can be
split between the two ADs in an area.  Part of that, though, is the founded on the
idea that the final review is built on a series of earlier "milestone reviews" done
by the working group and CREW.  With those done early in the process, shifting
the final review to per Area should help (note also that the INFO and EXP documents
aren't handled by the IESG in this proposal, which helps remove further load).


>4. Linked to this: I think we need a lot more debate about the reviewers. A vital part
>of the SIRs proposal (which has certainly not been tried yet) is for reviewers to stay
>with a document right from its birth up to the moment before the IESG decision. The draft
>talks about early review but doesn't talk about final review. This is linked to the
>previous point - to unload the IESG, a large part of the final review has to be done
>oustside the IESG. I think we need to think again about both the SIRs proposal (which
>has its problems) and the CREW proposal (which has its problems) and come up with
>a coherent answer. I doubt if this can be reduced to just a single section of a more
>general document.

I agree; a coherent theory of how review works in the IETF is critical to getting progress
here, and it will eventually need a specification of its own. Putting all these pieces
into a single outline document is more to get a sense of how they might fit together
and highlight areas for further work than to build a single monolitihic spec.



Thanks again for sharing your thoughts on this,
				regards,
					Ted Hardie