On Fri, 2005-04-29 at 12:19 -0400, Keith Moore wrote:
Let me also restate for clarity:
Let me restate for clarity - ADs aren't necessarily more technically
astute than *all* the rest of us. That is, we need to be careful that
technical input from ADs isn't automatically assigned extra weight or
control (veto power).
There's no way to avoid that happening and still have quality control.
Why is that? If an AD has a compelling reason that a specification
needs work, the AD should be able to make a convincing argument to the
IETF as a whole. Best way to do that is in an open conversation during
the IETF last call.
Which is why I suggest ADs provide technical input in open mailing lists
during last calls, to make sure their technical input is on the same
footing as everyone else's technical input. I agree that the IESG's job
is to ensure correctness, completeness, etc. That feedback should be
provided earlier, in an open forum.
I agree that input should be provided as early as possible. But some
kinds of feedback inherently follow Last Call,
Such as?
and limiting IESG input
to before Last Call would just serve to make the process even slower
than it already is (by requiring multiple IESG reviews rather than just
one),
I disagree - suppose the gating function comes *before* the IETF last
call: before a draft goes to IETF last call, the ADs all agree that they
are prepared (have cycles, aren't travelling, etc.) to review and
comment on the draft.
My experience has been that the there can be an unbounded delay between
the IETF last call and the IESG review.
while lowering publicatiortp-core-1.cisco.com (64.102.124.12)
by rtp-iport-1.cisco.com with ESMTP; 04 May 2005 00:42:38 -0400
X-IronPort-AV: i="3.92,152,1112587200";
d="scan'208"; a="47408644:sNHT1217819558"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
[64.102.31.102])
by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j444T4RS021662;
Wed, 4 May 2005 00:29:07 -0400 (EDT)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
Wed, 4 May 2005 00:29:05 -0400
Received: from 10.86.242.112 ([10.86.242.112]) by xmb-rtp-211.amer.cisco.com
([64.102.31.118]) via Exchange Front-End Server email.cisco.com
([64.102.31.113]) with Microsoft Exchange Server HTTP-DAV ;
Wed, 4 May 2005 04:29:04 +0000
Received: from localhost.localdomain by email.cisco.com;
04 May 2005 00:29:12 -0400
From: Ralph Droms <rdroms(_at_)cisco(_dot_)com>
To: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
In-Reply-To:
<20050429121933(_dot_)4c622ee6(_dot_)moore(_at_)cs(_dot_)utk(_dot_)edu>
References:
<20050428062402(_dot_)XZEM20133(_dot_)fep01-app(_dot_)kolumbus(_dot_)fi(_at_)mta(_dot_)im
ail.kolumbus.fi>
<20050428141236(_dot_)0f9a9fab(_dot_)moore(_at_)cs(_dot_)utk(_dot_)edu>
<51B6ED2812DB71A87A1BF836(_at_)scan(_dot_)jck(_dot_)com>
<20050428150045(_dot_)62a627e8(_dot_)moore(_at_)cs(_dot_)utk(_dot_)edu>
<42715967(_dot_)80508(_at_)isi(_dot_)edu>
<892331f072cf1b9741218f679fa366f3(_at_)cs(_dot_)utk(_dot_)edu>
<1114728905(_dot_)11628(_dot_)34(_dot_)camel(_at_)localhost(_dot_)localdomain>
<482f91815aa54a99c4d772a997e94554(_at_)cs(_dot_)utk(_dot_)edu>
<1114781735(_dot_)18867(_dot_)35(_dot_)camel(_at_)localhost(_dot_)localdomain>
<20050429121933(_dot_)4c622ee6(_dot_)moore(_at_)cs(_dot_)utk(_dot_)edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Tue, 03 May 2005 20:22:29 -0400
Message-Id:
<1115166149(_dot_)5285(_dot_)15(_dot_)camel(_at_)localhost(_dot_)localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-2)
X-OriginalArrivalTime: 04 May 2005 04:29:05.0008 (UTC)
FILETIME=[CE1E7700:01C55061]
X-Spam-Score: 0.7 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: text suggested by ADs
X-BeenThere: ietf(_at_)ietf(_dot_)org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request(_at_)ietf(_dot_)org?subject=unsubscribe>
List-Post: <mailto:ietf(_at_)ietf(_dot_)org>
List-Help: <mailto:ietf-request(_at_)ietf(_dot_)org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request(_at_)ietf(_dot_)org?subject=subscribe>
Sender: ietf-bounces(_at_)ietf(_dot_)org
Errors-To: ietf-bounces(_at_)ietf(_dot_)org
On Fri, 2005-04-29 at 12:19 -0400, Keith Moore wrote:
Let me also restate for clarity:
Let me restate for clarity - ADs aren't necessarily more technically
astute than *all* the rest of us. That is, we need to be careful that
technical input from ADs isn't automatically assigned extra weight or
control (veto power).
There's no way to avoid that happening and still have quality control.
Why is that? If an AD has a compelling reason that a specification
needs work, the AD should be able to make a convincing argument to the
IETF as a whole. Best way to do that is in an open conversation during
the IETF last call.
Which is why I suggest ADs provide technical input in open mailing lists
during last calls, to make sure their technical input is on the same
footing as everyone else's technical input. I agree that the IESG's job
is to ensure correctness, completeness, etc. That feedback should be
provided earlier, in an open forum.
I agree that input should be provided as early as possible. But some
kinds of feedback inherently follow Last Call,
Such as?
and limiting IESG input
to before Last Call would just serve to make the process even slower
than it already is (by requiring multiple IESG reviews rather than just
one),
I disagree - suppose the gating function comes *before* the IETF last
call: before a draft goes to IETF last call, the ADs all agree that they
are prepared (have cycles, aren't travelling, etc.) to review and
comment on the draft.
My experience has been that the there can be an unbounded delay between
the IETF last call and the IESG review.
while lowering publication quality (by preventing IESG from
objecting to valid technical issues noticed after Last Call, and perhaps
discovered while considering Last Call input, but not directly related
to issues raised in Last Call).
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
n quality (by preventing IESG from
objecting to valid technical issues noticed after Last Call, and perhaps
discovered while considering Last Call input, but not directly related
to issues raised in Last Call).
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf