On Sat, 2005-04-30 at 11:12 -0700, Dave Crocker wrote:
1. A Discuss may be asserted only when it pertains to a normative
concern that involves the viability of the specification.
As a practical matter, the line between normative and informative is
likely grey enough to make this suggestion unworkable...
interesting point. first question, then, is why has the ietf been finding it
important to make the distinction between the two?
I can't speak for the IETF as a whole; for the most part, classification
as normative/informative is pretty obvious. But, if a reviewer feels
strongly that something in a spec needs to be fixed, seems likely that
the reviewer will classify the issue as "normative".
second question is how do we distinguish between Discuss items that really do
pertain to "it won't work" and "it's unacceptably deficient" concerns, versus
an AD's personal preferences and whims?
I suggest we depend on the IETF as a whole ... by publishing and
discussing the Discuss comments on a widely read mailing list.
2. The AD raising the Discuss must post the details of their concern
to the mailing list targeted to that specification and must provide
clear direction as to how to cure the problem. Failing the ability to
provide the detail about how to From ietf-bounces(_at_)ietf(_dot_)org
Wed May 04 00:29:29 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DTBVo-0002lI-0L; Wed, 04 May 2005 00:29:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DTBVh-0002j1-7X
for ietf(_at_)megatron(_dot_)ietf(_dot_)org; Wed, 04 May 2005 00:29:21
-0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13383
for <ietf(_at_)ietf(_dot_)org>; Wed, 4 May 2005 00:29:18 -0400 (EDT)
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTBjh-000150-EY
for ietf(_at_)ietf(_dot_)org; Wed, 04 May 2005 00:43:50 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13)
by rtp-iport-1.cisco.com with ESMTP; 04 May 2005 00:42:48 -0400
X-IronPort-AV: i="3.92,152,1112587200";
d="scan'208"; a="47408686:sNHT29497300"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
[64.102.31.12])
by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j444T0e5023267;
Wed, 4 May 2005 00:29:16 -0400 (EDT)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by
xbh-rtp-201.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:05 +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: Dave Crocker <dcrocker(_at_)bbiw(_dot_)net>
In-Reply-To: <2005430111244(_dot_)130296(_at_)bbprime>
References: <2005430111244(_dot_)130296(_at_)bbprime>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Tue, 03 May 2005 20:32:24 -0400
Message-Id:
<1115166744(_dot_)5285(_dot_)25(_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.0495 (UTC)
FILETIME=[CE68C670:01C55061]
X-Spam-Score: 1.7 (+)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
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 Sat, 2005-04-30 at 11:12 -0700, Dave Crocker wrote:
1. A Discuss may be asserted only when it pertains to a normative
concern that involves the viability of the specification.
As a practical matter, the line between normative and informative is
likely grey enough to make this suggestion unworkable...
interesting point. first question, then, is why has the ietf been finding it
important to make the distinction between the two?
I can't speak for the IETF as a whole; for the most part, classification
as normative/informative is pretty obvious. But, if a reviewer feels
strongly that something in a spec needs to be fixed, seems likely that
the reviewer will classify the issue as "normative".
second question is how do we distinguish between Discuss items that really do
pertain to "it won't work" and "it's unacceptably deficient" concerns, versus
an AD's personal preferences and whims?
I suggest we depend on the IETF as a whole ... by publishing and
discussing the Discuss comments on a widely read mailing list.
2. The AD raising the Discuss must post the details of their concern
to the mailing list targeted to that specification and must provide
clear direction as to how to cure the problem. Failing the ability to
provide the detail about how to fix the specification, the AD must
engage in a dialogue that has the goal of specifying that detail.
I agree with the first clause; the concern must be explained and motivated
in detail. The WG - not the AD or the doc authors in isolation - should
develop the solution.
This raises two issues. One is that the focus of the suggestion is making
sure that an AD who asserts a late-stage veto is meaningfully obligated to
work constructively to remove it.
Agreed and such obligation (which is the usual case now) would be a good
thing.
The other is that working groups rarely develop solutions. Participants or
small sub-groups develop solutions; working groups review and approve.
Good point.
When a random participant raises a concern during specification development,
the working group can readily acknowledge the issue and add it to the
workload, or it can fail to gain traction. In the former case, the working
group takes responsibility for finding the solution. In the latter, the
issue
is, effectively, turned back to the person with the concern. It is up to
them
to find some way to get the working group to embrace the concern; the usual
way to do this is to propose a solution, so that the working group has a more
solid sense of the topic.
Now we move to a late-stage AD veto. The working group has put years of
effort in and lots of review. Here comes an AD -- typically one who has not
been involved until this point -- blocking progress by stating some concern.
If the concern is obviously valid to everyone, then there is no issue.
Everyone goes wow, we sure are glad you caught that, and goes off to fix it.
The problem is when the AD's concern is not obviously valid, or at least not
obviously valid as a valid reason for blocking progress.
Today, there is almost no cost to the AD in these situations and, therefore,
no pressure on them to be reasonable and constructive to resolve it.
So, without meaning any offense to the ADs, I suggest we lump random
participants, WG members, doc editors and ADs together when the spec is
reviewed - and ensure that all comments are published in the same forum
and given appropriate weight based on technical merit, as supported by
explanatory text when the comments are published.
- Ralph
We need to change limits and incentives, to fix this.
In order to deal with the issue of a pocket veto, whereby the AD is
intractable but maintains the veto, there needs to be a mechanism to
force review of the Discuss, either to assert that, indeed, it
involves a valid showstopper (failure) of the specification or that it
can be ignored.
such a mechanism already exists.
If you are referring to a classic Appeal, then that is too heavyweight and
onerous. The cost to the participant, of making an appeal, is significant.
If you are referring to something else, what is is and where is it documented?
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf