Re: Re: [Icar] Input based on SIRS experience
Dave Crocker <dhc@dcrocker.net> Mon, 12 January 2004 04:46 UTC
Received: from optimus.ietf.org ([132.151.1.19])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29927
for <icar-archive@odin.ietf.org>; Sun, 11 Jan 2004 23:46:00 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20) id 1AftxE-0008Pp-Lu
for icar-archive@odin.ietf.org; Sun, 11 Jan 2004 23:45:32 -0500
Received: (from exim@localhost)
by www1.ietf.org (8.12.8/8.12.8/Submit) id i0C4jWFm032343
for icar-archive@odin.ietf.org; Sun, 11 Jan 2004 23:45:32 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20) id 1AftxE-0008Pa-H4
for icar-web-archive@optimus.ietf.org; Sun, 11 Jan 2004 23:45:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29921
for <icar-web-archive@ietf.org>; Sun, 11 Jan 2004 23:45:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12)
id 1Aftx7-0006F6-00
for icar-web-archive@ietf.org; Sun, 11 Jan 2004 23:45:25 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
id 1AftsZ-00067R-00
for icar-web-archive@ietf.org; Sun, 11 Jan 2004 23:40:43 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org)
by ietf-mx with esmtp (Exim 4.12) id 1AftoL-0005yK-00
for icar-web-archive@ietf.org; Sun, 11 Jan 2004 23:36:21 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20)
id 1Afto2-0007yJ-Ro; Sun, 11 Jan 2004 23:36:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by optimus.ietf.org with esmtp (Exim 4.20) id 1Aftno-0007xn-R9
for icar@optimus.ietf.org; Sun, 11 Jan 2004 23:35:48 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29708
for <icar@ietf.org>; Sun, 11 Jan 2004 23:35:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12)
id 1Aftnh-0005xB-00
for icar@ietf.org; Sun, 11 Jan 2004 23:35:41 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
id 1AfthU-0005qZ-00
for icar@ietf.org; Sun, 11 Jan 2004 23:29:17 -0500
Received: from joy.songbird.com ([208.184.79.7])
by ietf-mx with esmtp (Exim 4.12) id 1Aftfs-0005kN-00
for icar@ietf.org; Sun, 11 Jan 2004 23:27:36 -0500
Received: from bbprime (jay.songbird.com [208.184.79.253])
by joy.songbird.com (8.11.6/8.11.6) with SMTP id i0C4YMc27689;
Sun, 11 Jan 2004 20:34:22 -0800
From: Dave Crocker <dhc@dcrocker.net>
To: <spencer@mcsr-labs.org>, "Icar \(E-mail\)" <icar@ietf.org>
X-Mailer: PocoMail 3.03 (1740) - EVALUATION VERSION
X-URL: http://www.pocomail.com/
Date: Sun, 11 Jan 2004 20:26:37 -0800
Message-ID: <2004111202637.788100@bbprime>
In-Reply-To: <01e501c3d8bf$7e382df0$0400a8c0@DFNJGL21>
Subject: Re: Re: [Icar] Input based on SIRS experience
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: icar-admin@ietf.org
Errors-To: icar-admin@ietf.org
X-BeenThere: icar@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/icar>,
<mailto:icar-request@ietf.org?subject=unsubscribe>
List-Id: Improved Cross-Area Review <icar.ietf.org>
List-Post: <mailto:icar@ietf.org>
List-Help: <mailto:icar-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/icar>,
<mailto:icar-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Spencer,
> Yeah, Margaret is also coming up with 200-300 reviewers needed, and
> we still have no idea how many we can get. :-{
The calculations along those lines all look reasonable. At the moment,
I'd class it as a problem we'd love to have. More realistically, yes,
we need to make sure we design a mechanism that is both useful and
scalable.
One thought is that good early reviewing might substantially alter what
is needed later.
Another is to note a separate line of discussion that essentially
distinguishes between some working group efforts that get more
attention, versus others that might get less.
> > My own thought is that formal publication (RFC and even I-D) is far
> > too much overhead. The only existing mechanism is the mailing
> > list. Creating a new
> > mechanism strikes me as too much effort, and added effort is a very
> > large barrier to adoption of this process.
>
> This may be correct, but it's tragic, if so. Most of our archives
> aren't that tractable, and some are REALLY grim
I think that long-term access to useful copies of all IETF working
materials -- other than the stuff we formally publish -- has major
benefit, for legal and academic purposes. But I view this as a distinct
issue. My current concern is that the review stuff not create a new
distribution and/or storage mechanism.
> > Opening up the IETF Tracker to working group chairs, and adding the
> > review construct and/or allowing free-form entries would help this
> > enormously. (Free-form means that the IETF does not have to
> > formally adopt the thing being
> > tracked. This means reviews -- and other activities -- could be
> > tracked much sooner than would be possible if we first have to get
> > IETF-wide approval of the review process.
>
> I guessed that by "free-form" you were thinking of using the
> mechanism to track reviews of documents that hadn't been adopted as
> WG documents yet. That's also a question.
It isn't the status of the document that I was thinking about. It was
the status of the _type_ of data being entered, in terms of IETF
formality and officialness.
If we simply let a working group chair put in any entry they want, the
tracker won't know what the state transitions need to be, but the
working group chair can set the state manually. This means they do not
need to wait for the IETF to define and approve the details beforehand.
> > I am not sure whether selection of reviewers, by requesters, needs
> > to be different than we set up.
> >
> > A web page with a list of bios, and a mailing list for sending
> > requests to is probably fine.
>
> The mailing list violates a concept Ted Hardie talked about in
> Minneapolis - that appeals to individuals work better than appeals to
> groups in the IETF. I think Ted is right. Requesters will really have
> to be bothered to wonder who needs to review a document, rather than
> posting a request and wishing reviewers would materialize.
The phenomenon of dissipated responsibility was first noted with the
murder of Kitty Genovese, in New York, with lots of bystanders who could
see each other, none of whom called the police.
That said, the queries that have come into the SIRS list have gotten
good response. However my point was not that all requests should come
to the list, but that the list and the biographies with email addresses
ought to be sufficient.
> > There is also the small matter of the SIRS reviews that have been
> > done...
>
> You are such a social scientist. How inconvenient that you should ask
> a question when we have no idea what the answer is!
The purpose of an experiment is to spawn more experiments...
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <http://brandenburg.com>
_______________________________________________
Icar mailing list
Icar@ietf.org
https://www1.ietf.org/mailman/listinfo/icar
- [Icar] Input based on SIRS experience Wijnen, Bert (Bert)
- Re: [Icar] Input based on SIRS experience Dave Crocker
- Re: [Icar] Input based on SIRS experience Dave Crocker
- Re: [Icar] Input based on SIRS experience Spencer Dawkins
- Re: Re: [Icar] Input based on SIRS experience Dave Crocker
- Review Board Scalability (was: Re: [Icar] Input b… James Kempf
- Re: Re: [Icar] Input based on SIRS experience Alex Rousskov
- Re: Review Board Scalability (was: Re: [Icar] Inp… Pekka Savola