[secdir] Fwd: timing of reviews

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 24 May 2013 09:12 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7C921F9643 for <secdir@ietfa.amsl.com>; Fri, 24 May 2013 02:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08ZbcJazcBjg for <secdir@ietfa.amsl.com>; Fri, 24 May 2013 02:11:55 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D371E21F967F for <secdir@ietf.org>; Fri, 24 May 2013 02:11:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 09027BE79 for <secdir@ietf.org>; Fri, 24 May 2013 10:11:29 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYute+XGPZLQ for <secdir@ietf.org>; Fri, 24 May 2013 10:11:26 +0100 (IST)
Received: from [10.87.48.5] (unknown [86.41.48.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1F630BE50 for <secdir@ietf.org>; Fri, 24 May 2013 10:11:26 +0100 (IST)
Message-ID: <519F2EBD.1030408@cs.tcd.ie>
Date: Fri, 24 May 2013 10:11:25 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: "secdir@ietf.org" <secdir@ietf.org>
References: <5E0AD376-F965-40AE-82E4-667D16E8313A@piuha.net>
In-Reply-To: <5E0AD376-F965-40AE-82E4-667D16E8313A@piuha.net>
X-Enigmail-Version: 1.5.1
X-Forwarded-Message-Id: <5E0AD376-F965-40AE-82E4-667D16E8313A@piuha.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [secdir] Fwd: timing of reviews
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2013 09:12:00 -0000

Folks,

Jari's mail below says it better than I could.

What do you think about this?

Thanks,
S.


-------- Original Message --------
Subject: timing of reviews
Date: Fri, 24 May 2013 01:28:48 +0300
From: Jari Arkko <jari.arkko@piuha.net>
To: General Area Review Team <gen-art@ietf.org>
CC: The IESG <iesg@ietf.org>

Thanks again for all your hard work in doing the reviews. They make it
possible for me to concentrate on reviewing just those documents where
there are problems or I have deeper expertise. And the quality of the
protocol specifications coming out of the IETF is obviously very
important, particularly for protocols that are gaining significant use.

As you may have seen, the IESG and the community has been wondering if
there'd be something that we could do about the IETF process, in the
sense that there's quite many things happening at the very end of the
document's life cycle. This results in some surprises, and often also
moves some important decisions out of the working group and to
author/shepherd/AD hands. A while ago we met for the IESG retreat and
wanted to experiment with three specific changes:

- sending work back to the WGs when significant changes are needed, and
making the WG the central place of the edits
- moving some directorate reviews earlier, without impact reviewer
effort too much
- inviting some of the shepherds onto tele chats

I am writing to you in order to discuss the second item. How big of a
change would it be to have Gen-ART reviews be invoked during WGLC, while
the documents are still in the working groups? The goal of the reviews
would still be the same, e.g., I would be checking that the reviews were
positive and/or that the issues brought up have been properly addressed.

There are important details to consider, however, and I would like to
get your feedback on how you would seem them having an effect, and what
would be the best way to organise this, if we decide to go ahead with
the change for the Gen-ART.

Triggering the review would have to be done by something else than IETF
last call announcement. Is the best approach is to have the WG chairs
manually request for this? Note that sometimes there are multiple WGLCs.
I presume that it would be preferable to have a Gen-ART review be done
only once at this stage, as otherwise the work load would increase. The
chairs may have some idea of whether they are likely to need another
WGLC before they start one.

There may be possibly bigger changes and time lag between the first
Gen-ART review and the one that checks that the changes are ok.

Some specs may not make it through WGLC, and a review at that stage may
increase the effort you guys are putting in, by reviewing those specs
that will fail.

Jari