A 100.000 foot perspective on "what is the problem"

[James Kempf]

Ran,

I do think that IESG direction late in the process leads to difficulties with
resentment on the part of the WG and blocks in the process, as Pete says and as
Marshall identified in his draft. Some ADs are involved informally in the
process all along, but given the work load, my experience is that they can only
realistically be involved in fire fighting what happen to be the most critical
issues, which often means the ones closest to moving to IESG review. I think it
would make everyone's job easier if we could introduce more predictibility into
the process, so that there were identifiable checkpoints prior to sending an ID
to the full IESG for review to become an RFC. These kinds of midcourse
corrections could help to make sure that last call and IESG review go more
smoothly.

            jak

----- Original Message -----
From: "RJ Atkinson" <rja@extremenetworks.com>
To: "Pete Resnick" <presnick@qualcomm.com>
Cc: <problem-statement@alvestrand.no>
Sent: Monday, December 16, 2002 12:26 PM
Subject: Re: A 100.000 foot perspective on "what is the problem"


>
> Pete,
>
> It might be that folks mean what you say below, but I am unable
> to determine whether or not that is the case -- since most folks aren't
> putting
> all those conditions into their public statements on this list or
> elsewhere.
>
> If folks do agree with Pete's assertion, it is useful to make that
> clearly known in public so that the commentary is understood correctly.
>
> Ran
>
> On Monday, Dec 16, 2002, at 14:17 America/Montreal, Pete Resnick wrote:
> > I think both of you are setting this up as two contradictory and
> > mutually exclusive choices. I don't think they are. One of the clear
> > messages you are hearing is "No surprises LATE IN THE PROCESS". I
> > think most folks would be happy with more IESG input if it happened
> > during protocol development. What I think gets people's knickers in a
> > twist (as James has mentioned) is that in most instances, the only
> > significant input a WG gets from the IESG is at the end of its
> > lifetime. Making course corrections during the process due to IESG
> > input is much less disruptive and can be easily incorporated into the
> > work. If WGs were getting that kind of input all along, Last Call and
> > IESG review *would* be a rubber stamp for all intents and purposes:
> > Except for the "Holy crap! How could we have missed that?!?"
> > occurrences (which will occasionally happen), most of the issues would
> > have been addressed by the WG during development.
> >
> > I think you could get consensus for, "The IESG needs to be more
> > aggressive in terms of steering IETF efforts *during the work* AND the
> > final IESG review of documents should be almost a rubber stamp (save
> > everyone dropping the ball) *at the end of the work*".
> >
> > Two caveats:
> >
> > 1. If it weren't taking WGs 2 years to get product out the door, the
> > red flags at the end of the process wouldn't seem so painful. The IESG
> > could probably get away with doing mostly end-game review without as
> > much complaining if WGs were producing documents in 3 to 6 months.
> >
> > 2. Doing cross-area review all along the way would be a HUGE
> > undertaking for the IESG at this point, especially considering their
> > current workload. I think eventually the during-the-process work would
> > lessen the backend load, but it would be no picnic at the get-go.
> >
> > So, all that said, I think "The IESG isn't agressive enough in terms
> > of steering AND the IESG won't leave us alone and just rubber stamp
> > our documents and pass them to the RFC Editor" isn't a completely
> > unreasonable description of a problem. (We are supposed to be
> > describing problems here, aren't we? ;-))
> > --
> > Pete Resnick <mailto:presnick@qualcomm.com>
> > QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
> >
>
>