On standards review panel and division of work

Pekka Savola <pekkas@netcore.fi> Thu, 04 August 2005 06:36 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ZKt-0001WK-M4; Thu, 04 Aug 2005 02:36:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ZKr-0001WC-3B for ietf@megatron.ietf.org; Thu, 04 Aug 2005 02:36:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03995 for <ietf@ietf.org>; Thu, 4 Aug 2005 02:36:07 -0400 (EDT)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Zrf-0007sK-RM for ietf@ietf.org; Thu, 04 Aug 2005 03:10:05 -0400
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j746Zt126239 for <ietf@ietf.org>; Thu, 4 Aug 2005 09:35:56 +0300
Date: Thu, 04 Aug 2005 09:35:55 +0300
From: Pekka Savola <pekkas@netcore.fi>
To: ietf@ietf.org
Message-ID: <Pine.LNX.4.61.0508040933500.25912@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Subject: On standards review panel and division of work
X-BeenThere: ietf@ietf.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@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Hi,

Margaret's commentary on the standards review panel got me thinking of 
the same thing I had considered potentially problematic.

If I understood her concern correctly, the point was that in the 
standards review panel, the IESG would basically still continue 
reviewing the documents (at least to some degree) -- there seems to be 
an expectation that they should form an opinion on them (to be 
attached to the review request to be sent to the review panel).

When I read the document, my assumption was that the IESG could reduce 
the amount of review significantly, and possibly even remove it 
completely. There is indeed a danger that the present model could 
continue (compare also to the previous RFC-editor submission review, 
which wasn't supposed to be all that thorough in the first place!).

I do not think this is a show-stopper though; as many details in the 
proposal, things like these can be modified.  In this case, I believe 
the problem can be easily addressed by giving the ADs the power to 
initiate the review requests to the review panel -- and encouraging 
them to do so.

This would have several benefits:
  * if the expectation would be that drafts would be brought before
    the full IESG only in exceptional cases, the load and duplication
    of review would not increase significantly.

  * if there would be no full IESG review, it would force the IESG
    members to ensure the drafts have been sufficiently cross-area
    reviewed before requesting advancement (this is obviously also
    chairs' responsibility) -- ensuring earlier review.

  * again, if there would be no full IESG review, it would force the
    IESG members who have a personal interest to participate during the
    IETF last call (or even earlier) if they want to perform personal
    review.

  * it would remove the full IESG review and place it to the different
    equivalent body, the review body.

I don't see any disadvantages, except that if there hasn't been 
sufficient cross-area review before requesting the review panel to 
review, they might have to shuttle the documents back and forth more 
often.  This approach might also call for IETF-wide vetting of also 
WG-produces informational/experimental documents, if they would be 
reviewed by fewer people, but if this would be needed, it could be 
easily added later on and isn't worth considering at this point.

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

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf