[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: PROTO Process
I's not sure what side of the fence Eric is sitting on here.
I have a view that in many cases the IESG is trying to do too much to a document. Certainly I do not believe it is an IESG function to add value. I suspect the process should be more clear cut of either approving the document warts and all, or deciding it is not publication ready and sending it back to the working group with a clear description of why the document could not be published.
That would solve the "buried in the IESG" problem in one quick process change, and encourage the issues with the documents to get out on the working group lists, which is what fails to happen at the moment.
If the document is really wrong, they can work on it again.
For a number of the IESG comments I have seen have come from our own area directors, I believe they should really have been made as individuals during the consensus building process in the WG, rather than as IESG comments.
regards
Keith
> -----Original Message-----
> From: wgchairs-bounces at ietf.org
> [mailto:wgchairs-bounces at ietf.org] On Behalf Of Eric Burger
> Sent: Thursday, May 14, 2009 6:29 PM
> To: Working Group Chairs
> Subject: Re: PROTO Process
>
> +1. On the one hand, most of the documents I have been shepherding
> have not had the "lost in IESG" issue Jari mentions.
> However, I have on numerous occasions had the impression that
> some ADs really wanted to "add value" to a document. If
> there was a procedure to correct this, I am all for it!
>
> On May 13, 2009, at 5:05 PM, Fred Baker wrote:
>
> >
> > On May 13, 2009, at 7:17 AM, Andrew Sullivan wrote:
> >> The alternative explanation is that the "have to be
> modified" could
> >> be stated slightly differently as "have to be modified to get
> >> through" AD review, which is the sort of thing I sometimes hear
> >> people saying. This locution suggests that people do not
> regard the
> >> IETF and AD reviews as useful tests that improve the technical
> >> quality of a document, but that instead the reviews are
> regarded as
> >> hurdles to clear on the way to publishing an RFC. This
> might suggest
> >> a reluctance to compromise that is not ideally matched for our
> >> consensus-based approach. If that's right (and I don't
> know whether
> >> it is), then no procedural tweaks will fix it either, because the
> >> problem is still the suitability of the documents for
> publication as
> >> RFCs unless we abandon rough consensus as a test.
> >
> > Having been on both sides of this divide, I think I can attest that
> > both views hold water.
> >
> > As IETF chair and with Scott Bradner as one of the ADs, I
> noted that
> > any draft that used normative language and didn't cite RFC
> 2119 would
> > get a "discuss" on the point, and included that in my (decade- old
> > now) id nits bullet list simply to avoid the predictable revision
> > cycle. As an author on what is now RFC 4192, I found a
> particular AD
> > to be using his position on the IESG as leverage to force into the
> > document a statement which was both vacuous and untrue -
> and which the
> > working group had not discussed. I asked him for text
> supporting his
> > position, which he didn't supply, and his "discuss" was
> removed when
> > he left the IESG. Those are both cases of "what it took to get past
> > the IESG".
> >
> > On the other hand, at least in my opinion, the original L2TP draft
> > sent to the IESG was largely incomprehensible. Tom Narten's efforts
> > with the authors, centered around "I'm not removing my 'discuss'
> > until I can understand your document", resulted in a
> complete rewrite,
> > which was a vast improvement. While that was an extreme case, I can
> > think of many cases in which IESG comments have improved
> documents in
> > real ways.
> >
> > As an author, I sometimes get the feeling that ADs place discusses
> > because they feel honor-bound to find something wrong with
> a document.
> > I personally would appreciate getting those remarks during
> the working
> > group process rather than having the AD wait for last call to place
> > them. I appreciated Magnus' detailed comments on a draft I
> am working
> > on in behave coming now rather than later, as they
> constitute a lot of
> > additional effort - effort that was not deemed necessary when SIIT,
> > which the draft updates, was first proposed. In general, I
> think that
> > directorate review and AD review works best if it happens during
> > working group discussion rather than as a remedial effort after the
> > fact.
>
>