Re: [apps-review] Suggested changes for Applications Area Review Team

Claudio Allocchio <Claudio.Allocchio@garr.it> Sat, 19 March 2011 18:52 UTC

Return-Path: <Claudio.Allocchio@garr.it>
X-Original-To: apps-review@core3.amsl.com
Delivered-To: apps-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 258A63A69A1 for <apps-review@core3.amsl.com>; Sat, 19 Mar 2011 11:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.444
X-Spam-Level:
X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=-1.155, BAYES_00=-2.599, SARE_URGBIZ=0.725, URG_BIZ=1.585]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQexp5RHz4rD for <apps-review@core3.amsl.com>; Sat, 19 Mar 2011 11:52:46 -0700 (PDT)
Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by core3.amsl.com (Postfix) with ESMTP id 60BA73A699C for <apps-review@ietf.org>; Sat, 19 Mar 2011 11:52:44 -0700 (PDT)
Received: from mac-allocchio3.garrtest.units.it (mac-allocchio3.garrtest.units.it [140.105.201.3]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.4/8.14.4) with ESMTP id p2JIrwSQ024316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Mar 2011 19:54:00 +0100 (CET)
X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p2JIrwSQ024316
DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=lEcvTKvHw6a/T3ZfDJUtc/VfZVnhimZgzzBDOZ712qX2fbgZLZEfmXa/i++QqWUTp NrIVsnZHDHuQ1vKvCVmLk1TjwxA8cF0W7hNh3NU2lXovil9vPcKjLziNAN8W9pFraz+ 5dRGl5nDAOd70OPsz+R2Z1NXNLUBCEK/S6RFpGw=
Date: Sat, 19 Mar 2011 19:53:58 +0100
From: Claudio Allocchio <Claudio.Allocchio@garr.it>
X-X-Sender: claudio@mac-allocchio3.garrtest.units.it
To: SM <sm+ietf@elandsys.com>
In-Reply-To: <6.2.5.6.2.20110318165117.0d43e6e0@elandnews.com>
Message-ID: <alpine.OSX.2.02.1103191937410.1042@mac-allocchio3.garrtest.units.it>
References: <6.2.5.6.2.20110318165117.0d43e6e0@elandnews.com>
User-Agent: Alpine 2.02 (OSX 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Cc: Pete Resnick <presnick@qualcomm.com>, apps-review@ietf.org
Subject: Re: [apps-review] Suggested changes for Applications Area Review Team
X-BeenThere: apps-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Apps Area Review List <apps-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-review>
List-Post: <mailto:apps-review@ietf.org>
List-Help: <mailto:apps-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Mar 2011 18:52:47 -0000

I just add to the other comments... it looks quite good in general, but:

> If a reply is not provided within 24 hours of the request for review, it is 
> assumed that the reviewer will be able to perform the review before the 
> deadline.

but this is not ok. Implicit ACK is bad, because we still do not have 
internet on airplanes everywhere... and it might happen that we end up on 
top of some mountain where there is no Internet connection (even if, as 
you see, we answer email also on Saturday evening  :-)  ).

Please change the implicit ACK with an explicit ACK, and 24 hours is 
really only for very urgent requests (IESG queue) and should be used only 
a very short urgent reviews. 2 *working* days is much more likely to 
accomodate all.

> (i)   This draft is ready for publication as an Experimental RFC
>
> (ii)  This draft is almost ready for publication as an Informational RFC but
>       has a few issues that should be fixed before publication
>
> (iii) This draft is not ready for publication as a Proposed Standard and
>       should be revised before publication

well, the above does not cover all possible compbinations, and 
"structuring" too much requires a full list of combinations. Or... the 
above are just "examples" of short summaries.

and Yes... IETF style application of the guidelines ("rough common sense") 
works better than literals. :-)

all the best!

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio@garr.it
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca