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