Subject: [Icar] I-D ACTION:draft-zinin-icar-arts-00.txt

From: [email-masked]
Date: Mon, 15 Mar 2004 15:55:20 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Area Review Teams for Early Cross-functional Reviews
	Author(s)	: A. Zinin
	Filename	: draft-zinin-icar-arts-00.txt
	Pages		: 11
	Date		: 2004-3-15
	
This document contains a proposal for cross-functional IETF review
   process that can be initiated at early stages of a document life
   cycle. The approach is based on existing experience with area
   directorates and other expert groups within the IETF.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zinin-icar-arts-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-zinin-icar-arts-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-zinin-icar-arts-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Mar 2004 23:35:41 +0200 (EET)

>    directorates and other expert groups within the IETF.

It seems this is just re-publication of the earlier draft under the 
icar name.. as was apparently requested in the minutes.  I recall 
sending in some feedback to the previous version, but I guess the 
document will be revved later on.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Icar mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/icar

---

From: Alex Zinin <[email-masked]>
Date: Thu, 18 Mar 2004 11:17:53 -0800

Pekka,

 Yes, and yes.
 Thanks for the reminder! ;)

-- 
Alex
http://www.psg.com/~zinin/

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Mar 2004 10:28:25 +0100

I realise this is an oldish version but I do have a few comments...

>  2.1 Overview
> 
>    Briefly, the cross-functional review process may be described as fol-
>    lows.
> 
>    Each area has an area review team (ART) which ADs delegate the
>    interim document review function to. When necessary (early in the
>    process, or during the WG Last call, or both), the WG chairs request
>    the review for a document by sending an e-mail to all required ARTs
>    (at a minimum the ART of the area the WG belongs to). 

I don't see why it has to be the WG chairs, in the case of early review.
As soon as a document is in serious discussion, I think the authors should
be able to request a review. We should be strongly encouraging early review.

If it is a review required as part of a last call process, it's fine that
the WG chairs request it - but that is already too late for the first
cross-area review.

The other advantage of allowing authors to request review is that it
provides a path for early review of independent submissions. That is
a hole in the draft.

>  2.3 Area Review Teams
...
>    Selection of the ART members is done personally by the ADs. Possible
>    variations, however, may include open call for nominations, followed
>    up by ADs interviewing the candidates and personally approving them.

This does not follow from assumption 2 in section 2.2. On the contrary, if
the objective is to maintain trust in the ADs --or more accurately, to extend
that trust to the ART-- there must be some degree of community process in
creating the team. I think an open call should be obligatory, and an open
call for confidential comments. After that, it's OK for the AD to decide.

>    When a document needs to be reviewed by ART, the AD assigns two ART
>    members as "token holders". All ART members are encouraged to review
>    the document, however, the token holders are held responsible for
>    providing comments within a 2-week time frame and following up on
>    them with the document authors and/or the hosting WG. 

2 weeks is really very tough if we are talking about deep review of
serious specs. I wouldn't like to be asked to review NFSv4 in 2 weeks.

> 2.5 Role of Cross-Area Review within the Standards Process
...
>           Note that ADs are given a tool they can use to off-load docu-
>           ment review to the extent they believe is necessary, but they
>           are not required to do so. It is then left to the ADs to make
>           sure they are using this tool appropriately and sufficiently.

I can't quarrel with these words, but somehow they don't get the point
that *early* cross area review, before the document gets anywhere near
an AD, should significantly increase document quality and reduce the
need for detailed review at the end of the process.

> 
>  2.6 Initiation of Review Process
> 
>    The cross-functional review process can be initiated either by an AD
>    or by a WG chair after consultation with the ADs.

As noted above, I believe that authors should be *encouraged* to initiate
early review themselves. Don't put the load at the end of the process - put
it as early as possible.

>    The review process may be initiated at an early stage of a document
>    (e.g. when the WG is starting to consider an approach) to ensure
>    architectural validity and correctness of the general direction

This should be "should" IMHO.

>    The same process may be used by the ADs and the RFC-Editor to request
>    cross-functional review for individual submissions they are shepherd-
>    ing or checking for conflicts.

This should be a separate section with its own headline, and should be 
a "should" IMHO. I would be very concerned to see a duplication of review
teams for independent submissions.

   Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 26 Mar 2004 06:48:15 -0600

From: "Brian E Carpenter" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, March 26, 2004 3:28 AM
Subject: [Icar] Re: I-D ACTION:draft-zinin-icar-arts-00.txt

> I realise this is an oldish version but I do have a few comments...

FWIW, I read almost all Brian's comments as "somebody besides ADs and
WG chairs needs to be worried about getting review that is wide enough
and early enough, and document authors/editors are the obvious
stuckees". I agree.

It's pretty tempting to slap out a proposal that assumes that the
management structure needs to do something, but we'd be better off if
everyone contributed. I know it's hard to step back, but I'd ask
people to try to think about ICAR as a community responsibility, and
not just another thing for ADs and WG chairs to worry about.

Spencer

---

From: Mark Allman <[email-masked]>
Date: Mon, 29 Mar 2004 09:24:20 -0500

> not just another thing for ADs and WG chairs to worry about.

I have not made up my mind about this yet.  But, if I could play the
devil's advocate for a moment, I'd wonder .... The review team is only
so big.  And, the community produces *a lot* of documents.  So, in some
sense if the request has to come from a WG chair then that is a first
gate to making sure the document being reviewed is something the IETF
potentially cares about.  We want to get very early input and so the bar
for the WG chair to request review would be low (i.e., "this looks like
something the WG might take up", not "the WG just took this doc up").
But, might that be better than allowing just anyone to throw anything to
the review team?

Or, is the review team DDoS attack just me looking for problems to
solve?

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Mar 2004 17:13:43 +0200

Mark,

> Or, is the review team DDoS attack just me looking for problems to

The i-d-announce list is the DDoS attack today. Targetted requests for
early review might actually reduce that effect. But there is a risk, which
is why I would ideally want to see some Web tooling for requesting reviews,
able to respond "No, Brian already has 17 drafts in his review queue, try
Mark instead."

    Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 29 Mar 2004 13:37:53 -0600

From: "Brian E Carpenter" <[email-masked]>
To: <[email-masked]>
Cc: "Spencer Dawkins" <[email-masked]>; <[email-masked]>
Sent: Monday, March 29, 2004 9:13 AM
Subject: Re: [Icar] Re: I-D ACTION:draft-zinin-icar-arts-00.txt

> The i-d-announce list is the DDoS attack today. Targetted requests
for

I couldn't agree more, and note that i-d announcing with a cc: to a
reasonable mailing list is common practice today.

> able to respond "No, Brian already has 17 drafts in his review
queue, try

Brian, why do you need Web tooling? You can tell people this today,
whether it's true or not :-)

---

From: Mark Allman <[email-masked]>
Date: Mon, 29 Mar 2004 15:50:35 -0500

> The i-d-announce list is the DDoS attack today. 

Bingo.  This was my point.  No matter what web tooling you have if the
number of reviews you need is very large then you're still in deep.  So,
if you winnow that by having WG chairs do the requests for things that
are going to be considered (by the WG or for inclusion in a WG charter)
then maybe that is OK.

I am willing to believe that I am chasing daemons that are not there.

I am also betting that the additional work on the part of the chairs is
not much.  And, so, I'm willing to believe that it might be useful to
think about.

(And, I'll also say that I am mostly concerned with IETF documents, not
individual submissions.  If we were to include individual submissions
then the RFC Editor could easily take on the role of "WG chair" and
request review.)

> "No, Brian already has 17 drafts in his review queue, try Mark
> instead."

Actually, probably better to wait on Brian ... :-)

Thanks!

allman