Re: [secdir] Fwd: timing of reviews

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 24 May 2013 12:30 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 BD29C21F8F6D for <secdir@ietfa.amsl.com>; Fri, 24 May 2013 05:30:56 -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 iefn9CvCfsdS for <secdir@ietfa.amsl.com>; Fri, 24 May 2013 05:30:52 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B7B2021F8ED8 for <secdir@ietf.org>; Fri, 24 May 2013 05:30:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8EF9FBE8E; Fri, 24 May 2013 13:30: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 uVJrks1oxTxH; Fri, 24 May 2013 13:30:27 +0100 (IST)
Received: from [10.87.48.5] (unknown [86.41.48.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8041EBE79; Fri, 24 May 2013 13:30:27 +0100 (IST)
Message-ID: <519F5D63.4000206@cs.tcd.ie>
Date: Fri, 24 May 2013 13:30:27 +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: Tero Kivinen <kivinen@iki.fi>
References: <5E0AD376-F965-40AE-82E4-667D16E8313A@piuha.net> <519F2EBD.1030408@cs.tcd.ie> <20895.23252.179339.686278@fireball.kivinen.iki.fi>
In-Reply-To: <20895.23252.179339.686278@fireball.kivinen.iki.fi>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Jari Arkko <jari.arkko@piuha.net>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [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 12:30:56 -0000

Thanks Tero

That's useful info about the mechanics.

Also good to know you reckon WGLC might be a feasible
time for secdir reviews.

Others?

Cheers,
S.

On 05/24/2013 01:19 PM, Tero Kivinen wrote:
> Stephen Farrell writes:
>> Jari's mail below says it better than I could.
>>
>> What do you think about this?
> 
> I think one of the problems is that lately the IETF LC end time, and
> Telechat have been VERY close to each other. There are lots of
> documents coming in lately, where the IETF last call end date and the
> telechat date are same (for example draft-ietf-dhc-dhcpv6-radius-opt
> in last assignment) or there has been only one or two weeks between
> them (draft-ietf-ipsecme-dh-checks, draft-ietf-softwire-public-4over6
> in last assignment).
> 
> This makes it so that if reviewer finds some problems, there is no
> time to fix them before telechat. It used to be so that there was much
> bigger difference between the IETF LC and Telechat, and in that case
> there was even useful to do re-review at telechat time. Now there is
> no point to assign document to be re-reviewd at telechat time, as it
> was reviewed week or two earlier in the IETF LC time. 
> 
>> 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.
> 
> That would make it easier to address bigger issues, especially as the
> WG would at that point be more wiling to change things. Sometimes it
> seems that suggesting some bigger changes week or two before the
> telechat time, is not going to be accepted well by the document
> authors.
> 
>> 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.
> 
> The review tool currently takes the
> http://datatracker.ietf.org/feed/last-call/ rss feed and uses that to
> find the last calls. If there would be similar feed for WGLCs that
> would work fine from the tool point of view (I am not sure if there is
> anything like that now).
> 
> We would still need to follow IETF last call status as not all
> documents go through WGLC.
> 
> The review tool already supports quite easy way for secretary to add
> new documents to the list, i.e. WG can request earlier review and the
> document will be added to the tool for review at that point. The
> review tool also supports delegating the permission to add new
> documents to the review queue, so area-directors or selected members
> of the review team could add documents themselves.
> 
> The next question would be how many reviews we need. Currently we
> officially do two, one for IETF LC, and re-review at telechat time,
> but quite often there is no need to do the second review: reviewer
> already said document is ready, or his changes were already done. In
> those case I will not re-assign it for re-review (I usually do check
> the diffs between the last reviewed version and current version).
>