Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D4E21F8C14 for ; Wed, 28 Sep 2011 15:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 3TZCz07kxXEl for ; Wed, 28 Sep 2011 15:22:15 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD6C21F8C0C for ; Wed, 28 Sep 2011 15:22:15 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2032241CDA; Wed, 28 Sep 2011 16:29:01 -0600 (MDT) Message-ID: <4E839EBE.5080907@stpeter.im> Date: Wed, 28 Sep 2011 16:25:02 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20110928144706.096e9f40@elandnews.com> In-Reply-To: <6.2.5.6.2.20110928144706.096e9f40@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-review@ietf.org Subject: Re: [apps-review] New Apps Area Review Team member X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 22:22:16 -0000 On 9/28/11 3:58 PM, SM wrote: > Hi Sal, > > Welcome to the Apps Area Review Team. I added you to the apps-review > mailing list. There is a web page with the list of members at > http://www.apps.ietf.org/content/applications-area-review-team A list of > previous reviews is available at > http://www.apps.ietf.org/content/apps-review-tracker Welcome, Sal! > General note: Joshua Bell was unsubscribed from the mailing list as his > email address is no longer valid. If anyone on this list has his new > email address, could you please send it to me or ask him to email me? I think that Josh no longer has cycles for IETF work, but I will send you his email address off-list. Peter -- Peter Saint-Andre https://stpeter.im/ Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E46F21F8E09 for ; Wed, 28 Sep 2011 15:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.374 X-Spam-Level: X-Spam-Status: No, score=-101.374 tagged_above=-999 required=5 tests=[AWL=-1.189, BAYES_40=-0.185, 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 cwMmy0rozMQk for ; Wed, 28 Sep 2011 15:01:19 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0A64921F8E08 for ; Wed, 28 Sep 2011 15:01:18 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.26]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8SM3o1P016024; Wed, 28 Sep 2011 15:04:02 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1317247444; bh=TN1gvvro67zfgQgKN+dcyuZxWxw=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=phi3jSd44y3HwfRwr2UxtgYYgLpGD2wAG/9yhcbIj/VcuHS/cOd9YqapD+1ObdM01 GMEyHb71NsraYqTQ/KJcBV82vE1oeAQM549m284Fl5/2On2GhV8AQSbqtKKX+dfe3Z aIgUacv5LgD82wrebzDnE8RFfOxsxhT5QNGBltvM= Message-Id: <6.2.5.6.2.20110928144706.096e9f40@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 28 Sep 2011 14:58:01 -0700 To: Salvatore Loreto From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] New Apps Area Review Team member X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 22:01:20 -0000 Hi Sal, Welcome to the Apps Area Review Team. I added you to the apps-review mailing list. There is a web page with the list of members at http://www.apps.ietf.org/content/applications-area-review-team A list of previous reviews is available at http://www.apps.ietf.org/content/apps-review-tracker General note: Joshua Bell was unsubscribed from the mailing list as his email address is no longer valid. If anyone on this list has his new email address, could you please send it to me or ask him to email me? Best regards, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49AEA21F8C71 for ; Tue, 27 Sep 2011 08:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.419 X-Spam-Level: X-Spam-Status: No, score=-104.419 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067, 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 aY5yWMUJC1Lp for ; Tue, 27 Sep 2011 08:52:53 -0700 (PDT) Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by ietfa.amsl.com (Postfix) with SMTP id B634021F8C4B for ; Tue, 27 Sep 2011 08:52:53 -0700 (PDT) Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Sep 2011 08:55:39 -0700 Received: from 64.101.74.200 ([64.101.74.200]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Sep 2011 15:55:38 +0000 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 27 Sep 2011 09:55:37 -0600 From: Joe Hildebrand To: SM , Message-ID: Thread-Topic: [apps-review] Apps Area considerations Thread-Index: Acx9LeXX9sbkocKhtkuwHMNt5EE3Tw== In-Reply-To: <6.2.5.6.2.20110927080220.09eccc18@elandnews.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 27 Sep 2011 15:55:39.0365 (UTC) FILETIME=[E7404150:01CC7D2D] Subject: Re: [apps-review] Apps Area considerations X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 15:52:54 -0000 I added a section on status/error codes, and added a note to base64 about line feeds. The XML section needs a lot more. I'll see if I can add some stuff that other people will disagree with to start the discussion. On 9/27/11 9:29 AM, "SM" wrote: > Hello, > > In June 2010, there was a discussion about the web page at > http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues > There were some comments from several of you. The document is not > meant to be a review guide. I'll list the sections and the feedback: > > - ABNF and BNF > > There wasn't any comment. > > - Base64 > > There wasn't any comment. > > - Byte Order > > There wasn't any comment. > > - Dates and Times > > Martin mentioned http://www.w3.org/TR/2005/NOTE-timezone-20051013/ > > - Internationalization > > It was mentioned not to refer to RFC 2777. There is BCP 47 about > language tags. > > - IDNs > > This comes up every now and then. > > - Passwords > > The Precis work is not mentioned. > > - Media Types > > I don't recall any discussion about that. > > - Security > > Are people OK with RFC 6125? > > - Versioning > > This is usually an issue. > > - XML > > There wasn't any comment. > > I understand that there aren't any easy answers to some of the > above. However, if we cannot provide pointers to authors, it makes > their work more difficult. Is there any interest in cleaning up that web > page? > > Best regards, > -sm > > _______________________________________________ > apps-review mailing list > apps-review@ietf.org > https://www.ietf.org/mailman/listinfo/apps-review -- Joe Hildebrand Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B22921F8AC9 for ; Tue, 27 Sep 2011 08:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 WBWhe9MqU8MW for ; Tue, 27 Sep 2011 08:37:13 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9D121F8AAF for ; Tue, 27 Sep 2011 08:37:13 -0700 (PDT) Received: from [192.168.1.7] (adsl-68-122-32-32.dsl.pltn13.pacbell.net [68.122.32.32]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p8RFdr6K014340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Sep 2011 08:39:58 -0700 Message-ID: <4E81EE40.2070401@dcrocker.net> Date: Tue, 27 Sep 2011 08:39:44 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: apps-review@ietf.org References: <6.2.5.6.2.20110927080220.09eccc18@elandnews.com> In-Reply-To: <6.2.5.6.2.20110927080220.09eccc18@elandnews.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 27 Sep 2011 08:39:58 -0700 (PDT) Subject: Re: [apps-review] Apps Area considerations X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 15:37:13 -0000 On 9/27/2011 8:29 AM, SM wrote: > > - ABNF and BNF > > There wasn't any comment. I've modified the entry for this to be a bit more careful and accurate, since RFC 822 refers to its form of BNF as 'augmented'... However the focus of this entry is to highlight the need to have specs be careful to cite the form of BNF being used and I certainly agree with that. However it's a bit ironic that the BNF-checking tool that is cited does not declare what version /it/ checks against... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D804B21F8E7A for ; Tue, 27 Sep 2011 08:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 uRcXhCDJLJSx for ; Tue, 27 Sep 2011 08:29:53 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id ABDDF21F8E70 for ; Tue, 27 Sep 2011 08:29:53 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.235.137]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8RFWW3P000433 for ; Tue, 27 Sep 2011 08:32:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1317137559; bh=J88MLbbdUOLvwckoK0RbNOqpelo=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type; b=uVMhIcwO5M1l64+YEBv/NasYOBniu6OLG37eI28Ow4dyRdX5Wktv77vHBSwIzVcOp UkEMnE4g7l/ppGpFgjZTfyGc9P9cuaQUN5G85gH8ObL/pdt7ZZhp4EOZs5yJKYZjUU P09+mN+at/hrcUhBdGZzaYCQf84mNw5JMwlNBSO0= Message-Id: <6.2.5.6.2.20110927080220.09eccc18@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 27 Sep 2011 08:29:13 -0700 To: apps-review@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-review] Apps Area considerations X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 15:29:58 -0000 Hello, In June 2010, there was a discussion about the web page at http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues There were some comments from several of you. The document is not meant to be a review guide. I'll list the sections and the feedback: - ABNF and BNF There wasn't any comment. - Base64 There wasn't any comment. - Byte Order There wasn't any comment. - Dates and Times Martin mentioned http://www.w3.org/TR/2005/NOTE-timezone-20051013/ - Internationalization It was mentioned not to refer to RFC 2777. There is BCP 47 about language tags. - IDNs This comes up every now and then. - Passwords The Precis work is not mentioned. - Media Types I don't recall any discussion about that. - Security Are people OK with RFC 6125? - Versioning This is usually an issue. - XML There wasn't any comment. I understand that there aren't any easy answers to some of the above. However, if we cannot provide pointers to authors, it makes their work more difficult. Is there any interest in cleaning up that web page? Best regards, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C5721F8B5F for ; Sun, 25 Sep 2011 05:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, 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 nb2ao1IX6DyY for ; Sun, 25 Sep 2011 05:46:16 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6B2321F8B5B for ; Sun, 25 Sep 2011 05:46:16 -0700 (PDT) Received: by gxk19 with SMTP id 19so4602308gxk.31 for ; Sun, 25 Sep 2011 05:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fS0VajlL8FMYPv10V8layCFtsbb+N66aSNFpy/jJTcI=; b=HH5h96ucdfjcP+F4rwXRBwWamyBU2Wzs1iVeljLKmuCPbrhR5Td6XgRKwmjU7tQM3q rkxHzhPFjEiGpd+sXILe5bMkoXRZDyqUi7n9R7Fn7PgtyvgHoco2prDlW8kOVH06iCxt uDvO046ODLrcVLV6mfmMA7pTZH1pQWDYtobMo= MIME-Version: 1.0 Received: by 10.236.80.9 with SMTP id j9mr32800010yhe.94.1316954936367; Sun, 25 Sep 2011 05:48:56 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.42.198 with HTTP; Sun, 25 Sep 2011 05:48:56 -0700 (PDT) In-Reply-To: <4E7E81F1.1070005@it.aoyama.ac.jp> References: <4E7E81F1.1070005@it.aoyama.ac.jp> Date: Sun, 25 Sep 2011 08:48:56 -0400 X-Google-Sender-Auth: DuM1WbNZ6ogC1Z7JOurzMp8sCis Message-ID: From: Barry Leiba To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-review@ietf.org Subject: Re: [apps-review] Apps review team review request template X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2011 12:46:17 -0000 Martin says... > One thing I did which we currently don't say anything about is that I cc'= ed > the WG in charge of the document. This is mostly because if I'm in a WG t= hat > gets a review (e.g. security, gen-art), I'd also like to see these. I did mention that, in my original message that you quoted, and it's now on the wiki page: >> Reviewers: Please send all reviews to the apps-discuss list >> ([bold]not[/bold] to the apps-review list), and to the ".all" tools >> alias for the specification you are reviewing (see below)! =A0In cases >> where your review recommends significant changes to a working-group >> document, you should also consider copying the working group's mailing >> list. Barry Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E28221F8C0A for ; Sat, 24 Sep 2011 18:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.731 X-Spam-Level: X-Spam-Status: No, score=-99.731 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 8HtMUZfd6S7G for ; Sat, 24 Sep 2011 18:18:41 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id A9C6521F8BEB for ; Sat, 24 Sep 2011 18:18:40 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p8P1L40x021179 for ; Sun, 25 Sep 2011 10:21:07 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 322d_12c6_a3349f82_e714_11e0_88ac_001d096c5782; Sun, 25 Sep 2011 10:21:04 +0900 Received: from [IPv6:::1] ([133.2.210.1]:40992) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 25 Sep 2011 10:21:05 +0900 Message-ID: <4E7E81F1.1070005@it.aoyama.ac.jp> Date: Sun, 25 Sep 2011 10:20:49 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-review@ietf.org Subject: Re: [apps-review] Apps review team review request template X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2011 01:18:42 -0000 Just for the record - As one of the recent offenders, and probably the one who triggered this proposal, I agree with these changes. What I did when I wrote up the review was to look at an older example and follow that. Apparently, that was also mistaken, or was too old. One thing I did which we currently don't say anything about is that I cc'ed the WG in charge of the document. This is mostly because if I'm in a WG that gets a review (e.g. security, gen-art), I'd also like to see these. What do others think? Regards, Martin. On 2011/09/24 0:18, Barry Leiba wrote: > Hi, SM. > Seeing how many reviewers post their reviews to apps-review prompts me > to suggest a change to the up-front paragraph of your review request > template. I suggest this (example taken from a recent review > request): > > -------------------------------------------------- > OLD > Pete requested a review of draft-ietf-p2psip-base-18. The review has > been assigned to you and is due before September 4. > > NEW > Pete requested a review of draft-ietf-p2psip-base-18. The review has > been assigned to you and is due before September 4. Please post your > review to apps-discuss (see below), and DO NOT post it to apps-review. > -------------------------------------------------- > OLD > The review should be sent to apps-discuss, the authors, the IESG, the > WG Chairs and document shepherd, if applicable. > > NEW > The review should be sent to apps-discuss, the IESG, the authors, the > WG Chairs and document shepherd, if applicable. You can use the tools > alias draft-ietf-p2psip-base.all@tools.ietf.org to cover the authors, > chairs, and shepherd. If your review recommends significant changes > to a working-group document, you should also consider copying the > working group's mailing list. > > Suggested distribution: > To: apps-discuss@ietf.org, draft-ietf-p2psip-base.all@tools.ietf.org > cc: iesg@ietf.org > -------------------------------------------------- > > > I think that makes it easier for the reviewers to get it right, and > not all the reviewers know how to use the tools aliases, so I think > this will help. Want to try it? > > I would also update the wiki, but I can't see how to (can you tell > me?). If you want to, here's my suggestion for > http://www.apps.ietf.org/content/apps-review-template > > -------------------------------------------------- > OLD > This page provides a template for reviews provided by members of the > Apps-Review Team. > Reviewers: Please send all reviews to the apps-discuss list and make > sure to cc the author(s) of the specification you are reviewing! You > might also want to check out some samples, such as the reviews of > draft-wahl-ldap-p3p, draft-ietf-btns-c-api, > draft-ietf-calsify-2446bis, draft-merrick-jms-uri, and > draft-dusseault-http-patch-15. > > NEW > This page provides a template for reviews provided by members of the > Apps-Review Team. > > Reviewers: Please send all reviews to the apps-discuss list > ([bold]not[/bold] to the apps-review list), and to the ".all" tools > alias for the specification you are reviewing (see below)! In cases > where your review recommends significant changes to a working-group > document, you should also consider copying the working group's mailing > list. > > You might also want to check out some samples, such as the reviews of > draft-wahl-ldap-p3p, draft-ietf-btns-c-api, > draft-ietf-calsify-2446bis, draft-merrick-jms-uri, and > draft-dusseault-http-patch-15. > > Suggested distribution list for reviews: > To: apps-discuss@ietf.org, draft-name-without-version-num.all@tools.ietf.org > cc: iesg@ietf.org > -------------------------------------------------- > > Barry > _______________________________________________ > apps-review mailing list > apps-review@ietf.org > https://www.ietf.org/mailman/listinfo/apps-review > Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F63621F8B72 for ; Sat, 24 Sep 2011 14:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 wb7nF7UcdFzI for ; Sat, 24 Sep 2011 14:14:50 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCE021F8B71 for ; Sat, 24 Sep 2011 14:14:49 -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 p8OLHH8O051294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Sep 2011 23:17:17 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it p8OLHH8O051294 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=A2ChyYUBlzm9tlhwZ7ESZ+5CO8aeAAi5MFbwTzyrAxYkJeIFEVaq0NCgZ+en7gZcL pi5AV783n4QEFjEKMdmBrZ9Bb1lZ9FEq2Zss56c8m5Sb0WUrgA65CQdZR1d39yzcDAs Uo9t2xarZ+yyLcEthcuklsroA1/XJk2G5bHeeik= Date: Sat, 24 Sep 2011 23:17:16 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@lola02.garr.it To: Alexey Melnikov In-Reply-To: <4E7DE3EE.9010507@isode.com> Message-ID: References: <6.2.5.6.2.20110923145427.09b6c3b0@elandnews.com> <4E7DE3EE.9010507@isode.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: apps-review@ietf.org Subject: Re: [apps-review] Directorate X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 21:14:51 -0000 On Sat, 24 Sep 2011, Alexey Melnikov wrote: > SM wrote: > >> Hello, >> >> Most IETF areas have a directorate. In the Applications Area, there are >> the LDAP and XML Directorates. The only two review teams are Gen-ART and >> this team. I welcome your advice on whether it would be better if the >> review team is turned into a directorate. The advantages I can think of >> are: >> >> - It helps in your day job. >> >> - It may influence more reviewers to join the team. >> >> - I can ask you to do more early reviews. :-) >> >> I have not asked Apps ADs what they think about the idea. > > Are we going to get cool T-shirt and can we get expensive dinners covered? ...no ... somebody will just have more reason to tell that we are OLD with white long beards ! :-))) and they will say that we do not understand social networks, too ;-) besides jokes... well it will not help in my daily work, but it sems a probably correct formal definition for what we do ! ... but t-shirts and dinners are always welcome! > > _______________________________________________ > apps-review mailing list > apps-review@ietf.org > https://www.ietf.org/mailman/listinfo/apps-review > ------------------------------------------------------------------------------ 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 Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1191821F8A64 for ; Sat, 24 Sep 2011 08:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 HBcnDAnkMsEO for ; Sat, 24 Sep 2011 08:24:57 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0090C21F8672 for ; Sat, 24 Sep 2011 08:24:56 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.238.44]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8OFRQXl031633; Sat, 24 Sep 2011 08:27:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1316878053; bh=ngQAhWx4/9g4hWG60spGjmHdDyM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=bhNuxAfFNZa3QfIpTiXW/gBZCwMGTKVZ+HKDHwTnNLqm4svb9yBnUUAZCzCqwIjxn LkN20lbq7kr9+6jMVgQoL5hza7lR4fzNWVAByluqwWZws/7x3m6NHRyoNbW2kPRjNu YbF4b4U7wTtj8em83ns6XCerpMKbRyikPOelVIYk= Message-Id: <6.2.5.6.2.20110924071950.08e74e10@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 24 Sep 2011 08:25:39 -0700 To: Alexey Melnikov From: SM In-Reply-To: <4E7DE3EE.9010507@isode.com> References: <6.2.5.6.2.20110923145427.09b6c3b0@elandnews.com> <4E7DE3EE.9010507@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: Re: [apps-review] Directorate X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 15:24:58 -0000 Hi Alexey, At 07:06 24-09-2011, Alexey Melnikov wrote: >Are we going to get cool T-shirt and can we get expensive dinners covered? You already get a cool T-shirt by attending a meeting. As for expensive dinners, there is probably someone out there who would be more than happy to invite you if you are an AD. An AD's undivided attention does not come cheap these days. :-) Best regards, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2105A21F8B20 for ; Sat, 24 Sep 2011 08:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 VMPc5qhbk8UJ for ; Sat, 24 Sep 2011 08:08:29 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 35C6B21F8A64 for ; Sat, 24 Sep 2011 08:08:29 -0700 (PDT) Received: from [188.28.106.38] (188.28.106.38.threembb.co.uk [188.28.106.38]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 24 Sep 2011 16:11:05 +0100 Message-ID: <4E7DF303.5000109@isode.com> Date: Sat, 24 Sep 2011 16:10:59 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Barry Leiba References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-review@ietf.org Subject: Re: [apps-review] Apps review team review request template X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 15:08:30 -0000 Barry Leiba wrote: >Hi, SM. >Seeing how many reviewers post their reviews to apps-review prompts me >to suggest a change to the up-front paragraph of your review request >template. I suggest this (example taken from a recent review >request): > >-------------------------------------------------- >OLD >Pete requested a review of draft-ietf-p2psip-base-18. The review has >been assigned to you and is due before September 4. > >NEW >Pete requested a review of draft-ietf-p2psip-base-18. The review has >been assigned to you and is due before September 4. Please post your >review to apps-discuss (see below), and DO NOT post it to apps-review. >-------------------------------------------------- >OLD >The review should be sent to apps-discuss, the authors, the IESG, the >WG Chairs and document shepherd, if applicable. > >NEW >The review should be sent to apps-discuss, the IESG, the authors, the >WG Chairs and document shepherd, if applicable. You can use the tools >alias draft-ietf-p2psip-base.all@tools.ietf.org to cover the authors, >chairs, and shepherd. If your review recommends significant changes >to a working-group document, you should also consider copying the >working group's mailing list. > >Suggested distribution: > To: apps-discuss@ietf.org, draft-ietf-p2psip-base.all@tools.ietf.org > cc: iesg@ietf.org >-------------------------------------------------- > > >I think that makes it easier for the reviewers to get it right, and >not all the reviewers know how to use the tools aliases, so I think >this will help. Want to try it? > > This make sense. >I would also update the wiki, but I can't see how to (can you tell >me?). If you want to, here's my suggestion for >http://www.apps.ietf.org/content/apps-review-template > >-------------------------------------------------- >OLD >This page provides a template for reviews provided by members of the >Apps-Review Team. >Reviewers: Please send all reviews to the apps-discuss list and make >sure to cc the author(s) of the specification you are reviewing! You >might also want to check out some samples, such as the reviews of >draft-wahl-ldap-p3p, draft-ietf-btns-c-api, >draft-ietf-calsify-2446bis, draft-merrick-jms-uri, and >draft-dusseault-http-patch-15. > >NEW >This page provides a template for reviews provided by members of the >Apps-Review Team. > >Reviewers: Please send all reviews to the apps-discuss list >([bold]not[/bold] to the apps-review list), and to the ".all" tools >alias for the specification you are reviewing (see below)! In cases >where your review recommends significant changes to a working-group >document, you should also consider copying the working group's mailing >list. > >You might also want to check out some samples, such as the reviews of >draft-wahl-ldap-p3p, draft-ietf-btns-c-api, >draft-ietf-calsify-2446bis, draft-merrick-jms-uri, and >draft-dusseault-http-patch-15. > >Suggested distribution list for reviews: > To: apps-discuss@ietf.org, draft-name-without-version-num.all@tools.ietf.org > cc: iesg@ietf.org >-------------------------------------------------- > >Barry > Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428C221F8494 for ; Sat, 24 Sep 2011 07:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 JSd71eQ6jJ7J for ; Sat, 24 Sep 2011 07:16:56 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C592B21F8493 for ; Sat, 24 Sep 2011 07:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=52; q=dns/txt; s=iport; t=1316873974; x=1318083574; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Z09HikKA9D8EPNO2W+sR/XEh+oDRD9xn1Yqqed9A9Ic=; b=XwJ7XklD+JXYppZu0zLEiKGaXVH/sJCS5pc4nv3jmKZo11Pc4mmUl5QS Ck0V9JUEaYbSkOhZMZvT02CsZk0tVmUPzlWIudEGCGUWSaiz3bVMyKtHl HjQptk1S01GcwQzhwR03XK34IOXv0Cd26gAWogwln6DshXk8OCgIC9YbY c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMzlfU5Io8UT/2dsb2JhbABCDoRUozp4gVMBAQEBAxIBEFUBEAsaAgUWCwICCQMCAQIBRQYNAQcBAR6hBgGMQ5B9gSyEToERBJNSkHw5 X-IronPort-AV: E=Sophos;i="4.68,435,1312156800"; d="scan'208";a="4074428" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by mtv-iport-4.cisco.com with ESMTP; 24 Sep 2011 14:19:32 +0000 Received: from dhcp-10-61-102-217.cisco.com (dhcp-10-61-102-217.cisco.com [10.61.102.217]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8OEJURT025641; Sat, 24 Sep 2011 14:19:30 GMT Message-ID: <4E7DE6AE.1030905@cisco.com> Date: Sat, 24 Sep 2011 16:18:22 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <6.2.5.6.2.20110923145427.09b6c3b0@elandnews.com> <4E7D8396.3020008@it.aoyama.ac.jp> In-Reply-To: <4E7D8396.3020008@it.aoyama.ac.jp> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-review@ietf.org Subject: Re: [apps-review] Directorate X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 14:16:57 -0000 Either review team or directorate is fine with me. Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B073521F8AE6 for ; Sat, 24 Sep 2011 07:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 6JGYFZc-8R0m for ; Sat, 24 Sep 2011 07:04:10 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 203D621F8AD8 for ; Sat, 24 Sep 2011 07:04:10 -0700 (PDT) Received: from [188.28.106.38] (188.28.106.38.threembb.co.uk [188.28.106.38]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 24 Sep 2011 15:06:45 +0100 Message-ID: <4E7DE3EE.9010507@isode.com> Date: Sat, 24 Sep 2011 15:06:38 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: SM References: <6.2.5.6.2.20110923145427.09b6c3b0@elandnews.com> In-Reply-To: <6.2.5.6.2.20110923145427.09b6c3b0@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-review@ietf.org Subject: Re: [apps-review] Directorate X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 14:04:10 -0000 SM wrote: > Hello, > > Most IETF areas have a directorate. In the Applications Area, there > are the LDAP and XML Directorates. The only two review teams are > Gen-ART and this team. I welcome your advice on whether it would be > better if the review team is turned into a directorate. The > advantages I can think of are: > > - It helps in your day job. > > - It may influence more reviewers to join the team. > > - I can ask you to do more early reviews. :-) > > I have not asked Apps ADs what they think about the idea. Are we going to get cool T-shirt and can we get expensive dinners covered? Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86FF21F8713 for ; Sat, 24 Sep 2011 00:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.73 X-Spam-Level: X-Spam-Status: No, score=-99.73 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 9B5mjVCz5qHq for ; Sat, 24 Sep 2011 00:13:25 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id C779A21F86C1 for ; Sat, 24 Sep 2011 00:13:22 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p8O7Fn29027376 for ; Sat, 24 Sep 2011 16:15:50 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 0657_27a0_075bd4c8_e67d_11e0_9237_001d096c566a; Sat, 24 Sep 2011 16:15:48 +0900 Received: from [IPv6:::1] ([133.2.210.1]:39302) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 24 Sep 2011 16:15:50 +0900 Message-ID: <4E7D8396.3020008@it.aoyama.ac.jp> Date: Sat, 24 Sep 2011 16:15:34 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20110923145427.09b6c3b0@elandnews.com> In-Reply-To: <6.2.5.6.2.20110923145427.09b6c3b0@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-review@ietf.org Subject: Re: [apps-review] Directorate X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 07:13:25 -0000 I don't think this will help me in my day job, but looking at http://www.ietf.org/iesg/directorate/, it seems to fit what we are doing well, and the Gen-ART Review Team is already listed, so it seems to make a lot of sense even just for streamlining. Regards, Martin. On 2011/09/24 7:32, SM wrote: > Hello, > > Most IETF areas have a directorate. In the Applications Area, there are > the LDAP and XML Directorates. The only two review teams are Gen-ART and > this team. I welcome your advice on whether it would be better if the > review team is turned into a directorate. The advantages I can think of > are: > > - It helps in your day job. > > - It may influence more reviewers to join the team. > > - I can ask you to do more early reviews. :-) > > I have not asked Apps ADs what they think about the idea. > > Best regards, > -sm > > _______________________________________________ > apps-review mailing list > apps-review@ietf.org > https://www.ietf.org/mailman/listinfo/apps-review > Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B22C21F869E for ; Fri, 23 Sep 2011 20:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.024 X-Spam-Level: X-Spam-Status: No, score=-102.024 tagged_above=-999 required=5 tests=[AWL=-1.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, 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 lToOm0ELDd39 for ; Fri, 23 Sep 2011 20:07:04 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 27D3C21F8511 for ; Fri, 23 Sep 2011 20:07:04 -0700 (PDT) Received: by gyd12 with SMTP id 12so3677803gyd.31 for ; Fri, 23 Sep 2011 20:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=j+U9lieEXblVCWwFtcnWv1kTJlqlhj2gp5E0Tgadi9I=; b=pvj0dh02PDWUEF5FFV69z1cbBi96Ztr16ClWMpHuwRaofZJoKzU6998QFyAxeGvQEl 5G7eM0RuZsu3LjDcAjZvvKnCtceV+WsOw1PaSzXHgZ7XDBkq5zmwF9tFy61hf+3M9hW+ b+RnlqWYT/elxQVs6tVdu7S4u8iBbyNGVn+mM= MIME-Version: 1.0 Received: by 10.236.187.36 with SMTP id x24mr25746158yhm.74.1316833779902; Fri, 23 Sep 2011 20:09:39 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.83.8 with HTTP; Fri, 23 Sep 2011 20:09:39 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20110923145427.09b6c3b0@elandnews.com> References: <6.2.5.6.2.20110923145427.09b6c3b0@elandnews.com> Date: Fri, 23 Sep 2011 23:09:39 -0400 X-Google-Sender-Auth: n2zJGWt3r1HI_5gQduVvoX1JhE0 Message-ID: From: Barry Leiba To: SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-review@ietf.org Subject: Re: [apps-review] Directorate X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Sep 2011 03:07:04 -0000 > Most IETF areas have a directorate. =A0In the Applications Area, there ar= e the > LDAP and XML Directorates. =A0The only two review teams are Gen-ART and t= his > team. =A0I welcome your advice on whether it would be better if the revie= w > team is turned into a directorate. I see no reason not to formally change it to a directorate. Sounds good to= me. Barry Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B8821F8B88 for ; Fri, 23 Sep 2011 15:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 7jI2rbw57+Qz for ; Fri, 23 Sep 2011 15:34:56 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5E71521F8AFE for ; Fri, 23 Sep 2011 15:34:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.67]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8NMbJGl004294 for ; Fri, 23 Sep 2011 15:37:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1316817446; bh=mVFGzPiYmeViAWORBtKMGBcyBW8=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type; b=lIdjGAhq2ZnezUFwhcc3zmzcy0bMWWSbkE7kW51CcQsJZE9jv1RUEEsYTqNtBKanq kafWiykBby6g+iA5BZz+mkxzLdze/eyhqEun1Eaxw2qjOnkKTjNsODKd+tOF9VKQXY 8wT4Q17ZuJmyu7ZpSsLGBqNqf0KY+pxQYuDWcRLA= Message-Id: <6.2.5.6.2.20110923145427.09b6c3b0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 23 Sep 2011 15:32:41 -0700 To: apps-review@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-review] Directorate X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 22:34:57 -0000 Hello, Most IETF areas have a directorate. In the Applications Area, there are the LDAP and XML Directorates. The only two review teams are Gen-ART and this team. I welcome your advice on whether it would be better if the review team is turned into a directorate. The advantages I can think of are: - It helps in your day job. - It may influence more reviewers to join the team. - I can ask you to do more early reviews. :-) I have not asked Apps ADs what they think about the idea. Best regards, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659FD21F8CE8 for ; Fri, 23 Sep 2011 14:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.020, 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 40PboPipSRgJ for ; Fri, 23 Sep 2011 14:49:23 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9054021F8CE6 for ; Fri, 23 Sep 2011 14:49:23 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.67]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8NLpk7T002335; Fri, 23 Sep 2011 14:51:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1316814714; bh=ckIJ8vit68avCeC12vYNs74jNsY=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=R+xQwZqIh2o1EiVnDphC5TKkOUJew9Wm6wKfypOFeoKHKvkbFXgxUqODsXYS2uolF wLdaHw1MxuuLR8+2DpLFSIlpxR6V5qgG119C7t8opGuZm6pJD2FdgsGDBIrHHJBjeM 3EcXgwP/ZAwFyyotjXrx1Cuk4h1hbXtjBG73Ym0U= Message-Id: <6.2.5.6.2.20110923141321.09b2aca0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 23 Sep 2011 14:51:31 -0700 To: Barry Leiba From: SM In-Reply-To: References: <6.2.5.6.2.20110923131713.09b6ade8@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: Re: [apps-review] Apps review team review request template X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 21:49:27 -0000 Hi Barry, At 14:11 23-09-2011, Barry Leiba wrote: >I think it's not. I would mention pervasive or significant editorial >points (for example, if something is consistently wrong through the >document, or if the grammar is particularly bad, such that another >editor with better English skills should be added), but I wouldn't >bother picking small points in an early review. Thanks for the advice. I am going to follow it. >Ah. So this isn't plugged into the regular tools wiki, then? Can >that be changed? Or should we leave it? What do the ADs think? No, www.apps.ietf.org is not part of IETF infrastructure or run by the Tools teams. I had a short discussion about that with the Apps ADs last year. I preferred to leave it. Best regards, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C01921F8C79 for ; Fri, 23 Sep 2011 14:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.004 X-Spam-Level: X-Spam-Status: No, score=-103.004 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 0ik6itvofgM8 for ; Fri, 23 Sep 2011 14:09:05 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA38A21F8BFE for ; Fri, 23 Sep 2011 14:09:05 -0700 (PDT) Received: by gxk19 with SMTP id 19so3670471gxk.31 for ; Fri, 23 Sep 2011 14:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vi1WKwl5D8TSh7Mgr1ZcsPuSJX1nregJNdz+lue/6A4=; b=MclrqennvwQIAh6ktBqIFDOmlBDX+4c1Kyz17w9xJNhRtDqJJ25sR7+3mOnQpvs6Wj r46t1dCqTxt6XmazvpiHKP/2AyTi3bIlT7wAh50kIZw71NvWyITvTzK6TB881JUBrIw9 1j8eNqaD4WUAnECBkwD2mwdlNzwN48V9oJvXs= MIME-Version: 1.0 Received: by 10.236.77.195 with SMTP id d43mr25008226yhe.22.1316812300764; Fri, 23 Sep 2011 14:11:40 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.203.68 with HTTP; Fri, 23 Sep 2011 14:11:40 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20110923131713.09b6ade8@elandnews.com> References: <6.2.5.6.2.20110923131713.09b6ade8@elandnews.com> Date: Fri, 23 Sep 2011 17:11:40 -0400 X-Google-Sender-Auth: 2FOHMDowJXTcz8DSD0PZwqrsJCE Message-ID: From: Barry Leiba To: SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-review@ietf.org Subject: Re: [apps-review] Apps review team review request template X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 21:09:06 -0000 >> Seeing how many reviewers post their reviews to apps-review prompts me >> to suggest a change to the up-front paragraph of your review request >> template. =A0I suggest this (example taken from a recent review >> request): > > As a general comment, we send the review to apps-discuss as it has a wide= r > readership. Yes, I know. And when people post their reviews to apps-review instead, you wind up having to forward them to apps-discuss. Better if we can fend that off. > General comment, some of the reviews are early reviews, i.e. they are > performed before a Last Call has been initiated. =A0It is easier to ask f= or a > change and less work for the author/working group. =A0I don't ask for a C= c to > the IESG in such cases. =A0If the Apps ADs or anyone thinks that it is > appropriate to also copy the IESG in such cases, please let me know. No, I think it's fine as it is. Obviously, you'd adjust your text accordingly, recommending a cc to the IESG or not, as appropriate. > I would like to ask you whether it is worth picking editorial nits in an > early review. I think it's not. I would mention pervasive or significant editorial points (for example, if something is consistently wrong through the document, or if the grammar is particularly bad, such that another editor with better English skills should be added), but I wouldn't bother picking small points in an early review. >> I would also update the wiki, but I can't see how to (can you tell >> me?). =A0If you want to, here's my suggestion for > > Please ask Ned for a login for http://www.apps.ietf.org/user/ =A0If anyon= e > needs a login, feel free to email me. Ah. So this isn't plugged into the regular tools wiki, then? Can that be changed? Or should we leave it? What do the ADs think? Barry Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1797221F8C79 for ; Fri, 23 Sep 2011 13:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 oSe2xkPQlu3z for ; Fri, 23 Sep 2011 13:55:35 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3BE21F8C12 for ; Fri, 23 Sep 2011 13:55:35 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.67]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8NKvv2A032358; Fri, 23 Sep 2011 13:58:02 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1316811484; bh=7+rEUyrD8/DJFzhUGxLQyCu893U=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=cKh5Nw0zrYSMOnIrzE/up6ykOr6Ne0gpM2/YKsdjNkuNTrwE9B1F4Fh2laUxNRgk/ taEXjHujSimrxNG+aTiz9c8tZB63liSXxkymFOIQ4Yv2rtwcAMMC7KIM/8ZI+Z1LDS 2BYEA3dMb+1F3KiUzDJdoqbBD1Qq8mgTdvRzlSw0= Message-Id: <6.2.5.6.2.20110923131713.09b6ade8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 23 Sep 2011 13:56:37 -0700 To: Barry Leiba From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: Re: [apps-review] Apps review team review request template X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 20:55:36 -0000 Hi Barry, At 08:18 23-09-2011, Barry Leiba wrote: >Seeing how many reviewers post their reviews to apps-review prompts me >to suggest a change to the up-front paragraph of your review request >template. I suggest this (example taken from a recent review >request): Thanks for the thoughtful comments. I'll use your new text. As a general comment, we send the review to apps-discuss as it has a wider readership. >-------------------------------------------------- >OLD >The review should be sent to apps-discuss, the authors, the IESG, the >WG Chairs and document shepherd, if applicable. > >NEW >The review should be sent to apps-discuss, the IESG, the authors, the >WG Chairs and document shepherd, if applicable. You can use the tools >alias draft-ietf-p2psip-base.all@tools.ietf.org to cover the authors, >chairs, and shepherd. If your review recommends significant changes >to a working-group document, you should also consider copying the >working group's mailing list. Ok. General comment, some of the reviews are early reviews, i.e. they are performed before a Last Call has been initiated. It is easier to ask for a change and less work for the author/working group. I don't ask for a Cc to the IESG in such cases. If the Apps ADs or anyone thinks that it is appropriate to also copy the IESG in such cases, please let me know. I would like to ask you whether it is worth picking editorial nits in an early review. >Suggested distribution: > To: apps-discuss@ietf.org, draft-ietf-p2psip-base.all@tools.ietf.org > cc: iesg@ietf.org >-------------------------------------------------- > > >I think that makes it easier for the reviewers to get it right, and >not all the reviewers know how to use the tools aliases, so I think >this will help. Want to try it? I will try that. >I would also update the wiki, but I can't see how to (can you tell >me?). If you want to, here's my suggestion for Please ask Ned for a login for http://www.apps.ietf.org/user/ If anyone needs a login, feel free to email me. >http://www.apps.ietf.org/content/apps-review-template > >-------------------------------------------------- >OLD >This page provides a template for reviews provided by members of the >Apps-Review Team. >Reviewers: Please send all reviews to the apps-discuss list and make >sure to cc the author(s) of the specification you are reviewing! You >might also want to check out some samples, such as the reviews of >draft-wahl-ldap-p3p, draft-ietf-btns-c-api, >draft-ietf-calsify-2446bis, draft-merrick-jms-uri, and >draft-dusseault-http-patch-15. > >NEW >This page provides a template for reviews provided by members of the >Apps-Review Team. > >Reviewers: Please send all reviews to the apps-discuss list >([bold]not[/bold] to the apps-review list), and to the ".all" tools >alias for the specification you are reviewing (see below)! In cases >where your review recommends significant changes to a working-group >document, you should also consider copying the working group's mailing >list. > >You might also want to check out some samples, such as the reviews of >draft-wahl-ldap-p3p, draft-ietf-btns-c-api, >draft-ietf-calsify-2446bis, draft-merrick-jms-uri, and >draft-dusseault-http-patch-15. > >Suggested distribution list for reviews: > To: apps-discuss@ietf.org, > draft-name-without-version-num.all@tools.ietf.org > cc: iesg@ietf.org >-------------------------------------------------- That looks good. I posted your change. Feel free to edit it. Should the examples be updated? BTW, if you have notice any drafts from other areas that might benefit from an early review, please let me know. Best regards, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038DE21F8CC6 for ; Fri, 23 Sep 2011 08:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.005 X-Spam-Level: X-Spam-Status: No, score=-103.005 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 mCroltdKj1gw for ; Fri, 23 Sep 2011 08:16:24 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E65F21F8CA7 for ; Fri, 23 Sep 2011 08:16:24 -0700 (PDT) Received: by yxt33 with SMTP id 33so3377775yxt.31 for ; Fri, 23 Sep 2011 08:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=9hcvcgMEwnFAh/0GPVUlrKl1r0nQEHK/5E7qTZ9uZjk=; b=vzs2IeFMclgRFP4rAGiYYEjTKtjKG6WTxxCqek3WfjY4dV1oZ6Jn9tyIVOYXUJudLp BojHyAzDDGNypDrejCXfkCs9Tsn9Ox9e19z6YXCSiNrzJwL952JkGHBV4r5PiYGIjzHU DGnu8Dc1r5HBQt7sh3C3miw1795bDRNnKRU44= MIME-Version: 1.0 Received: by 10.236.152.8 with SMTP id c8mr22283449yhk.107.1316791138453; Fri, 23 Sep 2011 08:18:58 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.236.203.68 with HTTP; Fri, 23 Sep 2011 08:18:58 -0700 (PDT) Date: Fri, 23 Sep 2011 11:18:58 -0400 X-Google-Sender-Auth: iWGLs381ctUHWGQCmzL2Oq05-w4 Message-ID: From: Barry Leiba To: SM Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-review@ietf.org Subject: [apps-review] Apps review team review request template X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 15:16:25 -0000 Hi, SM. Seeing how many reviewers post their reviews to apps-review prompts me to suggest a change to the up-front paragraph of your review request template. I suggest this (example taken from a recent review request): -------------------------------------------------- OLD Pete requested a review of draft-ietf-p2psip-base-18. The review has been assigned to you and is due before September 4. NEW Pete requested a review of draft-ietf-p2psip-base-18. The review has been assigned to you and is due before September 4. Please post your review to apps-discuss (see below), and DO NOT post it to apps-review. -------------------------------------------------- OLD The review should be sent to apps-discuss, the authors, the IESG, the WG Chairs and document shepherd, if applicable. NEW The review should be sent to apps-discuss, the IESG, the authors, the WG Chairs and document shepherd, if applicable. You can use the tools alias draft-ietf-p2psip-base.all@tools.ietf.org to cover the authors, chairs, and shepherd. If your review recommends significant changes to a working-group document, you should also consider copying the working group's mailing list. Suggested distribution: To: apps-discuss@ietf.org, draft-ietf-p2psip-base.all@tools.ietf.org cc: iesg@ietf.org -------------------------------------------------- I think that makes it easier for the reviewers to get it right, and not all the reviewers know how to use the tools aliases, so I think this will help. Want to try it? I would also update the wiki, but I can't see how to (can you tell me?). If you want to, here's my suggestion for http://www.apps.ietf.org/content/apps-review-template -------------------------------------------------- OLD This page provides a template for reviews provided by members of the Apps-Review Team. Reviewers: Please send all reviews to the apps-discuss list and make sure to cc the author(s) of the specification you are reviewing! You might also want to check out some samples, such as the reviews of draft-wahl-ldap-p3p, draft-ietf-btns-c-api, draft-ietf-calsify-2446bis, draft-merrick-jms-uri, and draft-dusseault-http-patch-15. NEW This page provides a template for reviews provided by members of the Apps-Review Team. Reviewers: Please send all reviews to the apps-discuss list ([bold]not[/bold] to the apps-review list), and to the ".all" tools alias for the specification you are reviewing (see below)! In cases where your review recommends significant changes to a working-group document, you should also consider copying the working group's mailing list. You might also want to check out some samples, such as the reviews of draft-wahl-ldap-p3p, draft-ietf-btns-c-api, draft-ietf-calsify-2446bis, draft-merrick-jms-uri, and draft-dusseault-http-patch-15. Suggested distribution list for reviews: To: apps-discuss@ietf.org, draft-name-without-version-num.all@tools.ietf.org cc: iesg@ietf.org -------------------------------------------------- Barry Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2B721F8D02 for ; Thu, 22 Sep 2011 04:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.729 X-Spam-Level: X-Spam-Status: No, score=-99.729 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 OcXl-TFWINLk for ; Thu, 22 Sep 2011 04:46:01 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2E94D21F8D05 for ; Thu, 22 Sep 2011 04:46:01 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p8MBmRNv019814 for ; Thu, 22 Sep 2011 20:48:27 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 0ccd_9b82_c88c28b4_e510_11e0_b74b_001d096c5782; Thu, 22 Sep 2011 20:48:26 +0900 Received: from [IPv6:::1] ([133.2.210.1]:51266) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 22 Sep 2011 20:48:29 +0900 Message-ID: <4E7B207E.6020903@it.aoyama.ac.jp> Date: Thu, 22 Sep 2011 20:48:14 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Henning Schulzrinne , Hannes Tschofenig Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Marc Linsner , "apps-review@ietf.org" , ecrit@ietf.org, Robert Sparks Subject: [apps-review] review of draft-ietf-ecrit-lost-sync-12 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2011 11:46:02 -0000 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Document: draft-ietf-ecrit-lost-sync-12 Reviewer: Martin Dürst Review Date: September 22, 2011 Review Summary: This draft should be clarified in various places before being published. There is also a deeper design issue that I will mention upfront and that hopefully will be taken to heart for future work. Document Summary: The document defines a 'protocol' (actually a number of XML messages, under a common Media type, carried over http(s)) for synchronizing Location-to-Service Translation (LoST) service boundaries and mapping elements. Design Issue: It seems still in fashion to define a 'protocol' independent of underlying transport. This is preferable if there is a truely expected need for multiple transports, and if there is a large abstraction gap between the newly defined 'protocol' and the potential underlying transport mechanism. However, in the case at hand, only one transport (HTTP, including its secured equivalent HTTPS) is used, and the abstraction gap is extremely low. Once one has understood REST, it's very easy to see a set of mappings as a resource, a as a simple HTTP GET and a as a PUT. A with element would require some thought, although there are several possible solutions. Major Issues (necessary clarifications): Independence of LoST: The Introduction says: In any case, this document can also be used without the LoST protocol even though the format of the element is re-used from the LoST specification. What does "can be used without the LoST protocol" mean? If it said something like "this specification is independent of the LoST protocol specification except in that it reuses the element (and some error elements) from that specification", that would be easier to understand. Namespaces: It is overkill to define new namespaces for each spec. It's a well-known secret in the XML community that it's easily possible to add a number of new elements to an existing namespace. This would be very appropriate in this case, because the number of reused elements and attributes is quite large, and the number of new elements is low. This would simplify most of the examples. 4.2 Behavior of the LoST Sync Destination: This needs various clarifications. The first paragraph uses 'replace', the next one after the conditions uses 'update'. Is this the same? Then use the same word. Also, it says: If the received mapping M' does not update any existing mapping M then it MUST be added to the local cache as an independent mapping. If I apply this to a mapping with conditions 1. and 2. being true, but condition 3. being false, then this means that older mappings of the same source and sourceID MUST be added to the local cache. Surely this must be wrong. Also, it says that an emply element means that a "corresponding" mapping has to be determined based on source, sourceID, and lastUpdated. The "lastUpdated" here is ambiguous and could lead to differing implementations. Does lastUpdated have to match with equality? Does it have to be (the same or?) newer than the one being cached? Also, all the examples (Figs. 10/12) also contain an 'expires' attribute. Is that necessary? Does it have to be the same as the lastUpdated attribute? Please specify. Further, we have: "The element MAY carry a element": What kind of message element? If this is from RFC 5222, then please say so. In Fig. 12, there is a 'message' attribute, is that what is meant? If yes, then please fix the prose (element-> attribute). If no, then point out the difference. Fig. 12: This uses an attribute value for human-readable text. This is considered bad practice, because it forecloses the use of further markup in case this is considered necessary (can often become the case for internationalization reasons). in Transport, it says: The HTTP request MUST use the Cache-Control response directive "no-cache" to (*) HTTP-level caching At (*), a verb such as 'suppress' or 'avoid' or some such seems to be missing. Please clarify. In Operational Considerations, the use of XML Digital Signatures is mentioned. With just the text that is there, it seems impossible to guess what actually should be done. For example, how is authorization verified? Also, why only sign the first time? Wouldn't it be easier/more straightforward to just sign every time? This looks like either an afterthought (in which case the MUST isn't appropriate, because it doesn't have anything to do with the protocol per se) or some missing context (e.g. from LoST itself) in which case there should be some reference or so to clarify the context. Security Considerations: In particular the last two sentences read like security considerations not for synchronization, but for the underlying PSAP data and LoST itself. Probably similar considerations have already been given in RFC 5222 or elsewhere, in which case they should be included by reference. 9.1: "8-bit characters": This term is highly inappropriate, because it's actually 8-bit bytes, not characters. Please just point to RFC 3023. 9.1, security considerations: Replace the current text with a pointer to the security considerations in the spec (text similar to the "Published Specification" item) p. 25: The namespace document has the namespace as urn:ietf:params:xml:ns:lost1:sync, while in the examples it is urn:ietf:params:xml:ns:lostsync1. Please fix and check carefully. Minor Issues (mainly editorial): Abstract and Introduction: add a comma at end of clause The main data structure, the element, used for encapsulating information about service boundaries*,* is defined... p.4: "we call them Austria and Finland": "we call them" makes sense with fictive country names, but in this case "for example Austria and Finland" makes more sense. p. 8: "Node B issuing the first request and plays" -> "Node B is issuing the first request and plays" p. 12: There should be a short explanation of the element in the prose. 4.3: The first two example given with bullet points add a linebreak after the first attribute, it would be easier if they also added a linebreak after the second one. 6. Relax: Please add some introductory text. 7. Operational Considerations: When B obtained this new mapping it would find out that it has to distribute it to its peer C. C would also want to distribute the mapping to B (and vice versa). Either remove the 'vice versa' or the sentence before it. "If the originally mapping" -> "If the original mapping" Security Considerations: Split the long paragraph into shorter pieces for easier readability. 9.1, Additional Information: Please add "None" 10. In earlier times, the shepherd was called the PROTO shepherd. But these days, PROTO isn't used anymore as far as I know. Please remove. Regards, Martin. Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C077A11E8073 for ; Wed, 21 Sep 2011 16:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.482 X-Spam-Level: X-Spam-Status: No, score=-103.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 PrvImm4k00-X for ; Wed, 21 Sep 2011 16:21:48 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id D18B31F0D31 for ; Wed, 21 Sep 2011 16:21:47 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 21 Sep 2011 16:24:17 -0700 From: "Murray S. Kucherawy" To: Randall Gellens , "apps-review@ietf.org" , Barry Leiba Date: Wed, 21 Sep 2011 16:24:16 -0700 Thread-Topic: draft-ietf-appsawg-rfc3462bis Thread-Index: Acx4spgBBaJK8kL5QoKbNQLiJfi31gAAvKsg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-review] draft-ietf-appsawg-rfc3462bis X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 23:21:49 -0000 > -----Original Message----- > From: Randall Gellens [mailto:rg+ietf@qualcomm.com] > Sent: Wednesday, September 21, 2011 3:58 PM > To: apps-review@ietf.org; Murray S. Kucherawy; Barry Leiba > Subject: draft-ietf-appsawg-rfc3462bis >=20 > This document looks good. >=20 > One minor request: >=20 > In Section 4, under "Encoding considerations", I'd recommend either > deleting "are broken" or adding "or extended". (In my view, this > makes it easier for EAI.) >=20 > OLD: > Encoding considerations: 7-bit is sufficient for normal mail > headers, however, if the headers are broken and require encoding >=20 > NEW: > Encoding considerations: 7-bit is sufficient for normal mail > headers, however, if the headers require encoding >=20 > OR: > Encoding considerations: 7-bit is sufficient for normal mail > headers, however, if the headers are broken or extended > and require encoding Went with the latter in my working copy. Thanks! -MSK Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2E71F0D22 for ; Wed, 21 Sep 2011 16:00:17 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -105.886 X-Spam-Level: X-Spam-Status: No, score=-105.886 tagged_above=-999 required=5 tests=[AWL=0.713, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 NXw340CxxKnd for ; Wed, 21 Sep 2011 16:00:17 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id EC4971F0D21 for ; Wed, 21 Sep 2011 16:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=rg+ietf@qualcomm.com; q=dns/txt; s=qcdkim; t=1316646167; x=1348182167; h=message-id:x-mailer:date:to:from:subject:content-type: x-random-sig-tag; z=Message-Id:=20 |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|Date:=20Wed,=202 1=20Sep=202011=2015:57:47=20-0700|To:=20apps-review@ietf. org,=20Murray=20Kucherawy=20,=0D=0A=20 =20=20=20=20=20=20=20Barry=20Leiba=20|From:=20Randall=20Gellens=20 |Subject:=20draft-ietf-appsawg-rfc3462bis|Content-Type: =20text/plain=3B=20charset=3D"us-ascii"=20=3B=20format=3D "flowed"|X-Random-Sig-Tag:=201.0b28; bh=Z83oxKangU1uOvoQ+hhcFnZwrZY7vj9PVz3wHHe4TKU=; b=ux2B6NFle7yHYoYoHhnEo2XzfsdSfjOVi4sT61Gbqd43qT/n965a/wr+ dFqeWUS75XMUBN0lnE1UAI1rgwvSyse2U5ChzBpukwD0Dl+ZiA3Hsm5Tv oWrankcNACDFHlVQywKk9Cyb+S+oxXtO35yN85OpV4Z2ovpOuDG9kkRr3 0=; X-IronPort-AV: E=McAfee;i="5400,1158,6476"; a="120527460" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 21 Sep 2011 16:02:46 -0700 X-IronPort-AV: E=Sophos;i="4.68,417,1312182000"; d="scan'208";a="74799087" Received: from warlock.qualcomm.com ([129.46.50.49]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Sep 2011 16:02:46 -0700 Received: from loud.pensive.org (myvpn-l-00709.ras.qualcomm.com [10.64.136.131]) by warlock.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id p8LN2iIg005986; Wed, 21 Sep 2011 16:02:45 -0700 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Wed, 21 Sep 2011 15:57:47 -0700 To: apps-review@ietf.org, Murray Kucherawy , Barry Leiba From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Mailman-Approved-At: Thu, 22 Sep 2011 09:43:01 -0700 Subject: [apps-review] draft-ietf-appsawg-rfc3462bis X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2011 23:00:17 -0000 This document looks good. One minor request: In Section 4, under "Encoding considerations", I'd recommend either deleting "are broken" or adding "or extended". (In my view, this makes it easier for EAI.) OLD: Encoding considerations: 7-bit is sufficient for normal mail headers, however, if the headers are broken and require encoding NEW: Encoding considerations: 7-bit is sufficient for normal mail headers, however, if the headers require encoding OR: Encoding considerations: 7-bit is sufficient for normal mail headers, however, if the headers are broken or extended and require encoding -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Vous etes ici Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5381521F8B6C for ; Mon, 19 Sep 2011 02:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 lFW-ADMqSk-6 for ; Mon, 19 Sep 2011 02:31:03 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 27C0A21F8B28 for ; Mon, 19 Sep 2011 02:31:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.36]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8J9XDXW019928; Mon, 19 Sep 2011 02:33:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1316424804; bh=+Ijme1tCd0WXms7sAifj+esnh5A=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=HdTGW+B9XvArtuWTONH6th3yMvsNKWv490x+/gu420f04S0c3urD/40CZBkwFFqEn OJCM8gJ6jjY4LTGShz8B/7bIl0tJFWhMCzk8Qr6H1hIq9iC5T3yzfNsDx5Nssk36Mo bIc2ejo+H/bXCIcBobtQleM8HbIbqMpgS+TGf+D0= Message-Id: <6.2.5.6.2.20110919022152.0b135af8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 19 Sep 2011 02:24:31 -0700 To: "Martin J. Durst" From: SM In-Reply-To: <4E77070B.1020401@it.aoyama.ac.jp> References: <6.2.5.6.2.20110913083721.0a1b6598@elandnews.com> <6.2.5.6.2.20110913110834.0a015d20@elandnews.com> <6.2.5.6.2.20110917102744.0ac03ab8@elandnews.com> <4E77070B.1020401@it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-ietf-ecrit-lost-sync-12 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 09:31:04 -0000 Hi Martin, At 02:10 19-09-2011, Martin J. Durst wrote: >I should be able to review this, but would prefer to get some more >time, e.g. until Sept. 23. That's fine. Best regards, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F220A21F8B7E for ; Mon, 19 Sep 2011 02:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.542 X-Spam-Level: X-Spam-Status: No, score=-98.542 tagged_above=-999 required=5 tests=[AWL=-1.166, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 se+rC730ReIt for ; Mon, 19 Sep 2011 02:08:34 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id BEF6821F8573 for ; Mon, 19 Sep 2011 02:08:33 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p8J9AiD1024078 for ; Mon, 19 Sep 2011 18:10:49 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 7045_0546_4136d3dc_e29f_11e0_a480_001d096c566a; Mon, 19 Sep 2011 18:10:44 +0900 Received: from [IPv6:::1] ([133.2.210.1]:43427) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 19 Sep 2011 18:10:44 +0900 Message-ID: <4E77070B.1020401@it.aoyama.ac.jp> Date: Mon, 19 Sep 2011 18:10:35 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20110913083721.0a1b6598@elandnews.com> <6.2.5.6.2.20110913110834.0a015d20@elandnews.com> <6.2.5.6.2.20110917102744.0ac03ab8@elandnews.com> In-Reply-To: <6.2.5.6.2.20110917102744.0ac03ab8@elandnews.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-ietf-ecrit-lost-sync-12 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 09:08:38 -0000 Hello SM, On 2011/09/18 2:29, SM wrote: > Hi Martin, > > Could you please take over the review of draft-ietf-ecrit-lost-sync-12 > before September 21? I should be able to review this, but would prefer to get some more time, e.g. until Sept. 23. Regards, Martin. > Thanks, > -sm > > Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E8221F8A95 for ; Sat, 17 Sep 2011 10:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, 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 f6rx7IS9M7yD for ; Sat, 17 Sep 2011 10:27:57 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 3F37521F8A67 for ; Sat, 17 Sep 2011 10:27:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.38]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8HHU6DG025660; Sat, 17 Sep 2011 10:30:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1316280614; bh=7i8P8Lq1q7zpFXguGmu9OHugXZI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=ER2Tul/HRcj5U3986MDqyE3eFVze1vCTv2t7MRorTs96lT/+M9N3S5USdNpy6xD5J kBwKG6whgw8lfgpmbC8Ma7EWnrc8BKBO06kpCsyps1HmJwlugcLAQMzAw0sycFwG7P 3WKFvTKb2a02ahE5/G4IWrPakjmuWCW/eMMlyc8U= Message-Id: <6.2.5.6.2.20110917102744.0ac03ab8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 17 Sep 2011 10:29:54 -0700 To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= From: SM In-Reply-To: <6.2.5.6.2.20110913110834.0a015d20@elandnews.com> References: <6.2.5.6.2.20110913083721.0a1b6598@elandnews.com> <6.2.5.6.2.20110913110834.0a015d20@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-ietf-ecrit-lost-sync-12 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 17:28:01 -0000 Hi Martin, Could you please take over the review of draft-ietf-ecrit-lost-sync-12 before September 21? Thanks, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAD121F8C58 for ; Wed, 14 Sep 2011 11:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.698 X-Spam-Level: X-Spam-Status: No, score=-101.698 tagged_above=-999 required=5 tests=[AWL=-1.699, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_LOW=-1, 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 2vUH1oRzQugP for ; Wed, 14 Sep 2011 11:18:47 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id AA1B221F8BA9 for ; Wed, 14 Sep 2011 11:18:47 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 14 Sep 2011 11:20:57 -0700 From: "Murray S. Kucherawy" To: "teemu.savolainen@nokia.com" Date: Wed, 14 Sep 2011 11:20:56 -0700 Thread-Topic: apps-team review of draft-ietf-mif-dns-server-selection Thread-Index: AcxyrBw6zVCShQsaRQaFoCi5Am4oqAALTEuAAAtSoYA= Message-ID: References: <916CE6CF87173740BC8A2CE44309696202573D36@008-AM1MPN1-032.mgdnok.nokia.com> In-Reply-To: <916CE6CF87173740BC8A2CE44309696202573D36@008-AM1MPN1-032.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-ads@tools.ietf.org" , "apps-review@ietf.org" Subject: Re: [apps-review] apps-team review of draft-ietf-mif-dns-server-selection X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 18:18:49 -0000 > -----Original Message----- > From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] > Sent: Wednesday, September 14, 2011 6:56 AM > To: Murray S. Kucherawy > Cc: apps-review@ietf.org; apps-ads@tools.ietf.org; mif@ietf.org > Subject: RE: apps-team review of draft-ietf-mif-dns-server-selection >=20 > Thank you very much for your extensive review, I have replied and comment= ed > inline. I cc'd mif, apps-ads, and apps-review - hope it is ok. Fine with me, though I can't reply to mif since I'm not on it so I've dropp= ed it from this reply. Feel free to forward this as well. > Minor Issues: > . The IANA Considerations section seems to be a little understated. =A0I = would > suggest copying the one from RFC3646 and modifying it accordingly. >=20 > Teemu>Roger that, I updated my -05 candidate IANA considerations section = to > look following (as of now): > -- > This memo requests IANA to assign two new option codes. First option > code is requested to be assigned for DHCPv4 DNS Server Selection > option (TBD) from the DHCP option code space defined in section "New > DHCP option codes" of RFC 2939. Second option code is requested to > be assigned to the DHCPv6 DNS Server Selection option (TBD) from the > DHCPv6 option code space defined in section "IANA Considerations" of > RFC 3315. > -- That's probably good enough. It will be replaced again by the RFC Editor w= hen IANA does the assignment, but it's more clear here what you are request= ing. > . The use of "domain" in the first paragraph of Section 1 is ambiguous.= =A0 The > word "domain" is unfortunately overloaded to mean management domain, DNS > domain, and probably some others, plus the usual dictionary definition.= =A0 I > recommend simply saying "a solution for IPv6."=A0 Don't be surprised if a= DNS > Directorate reviewer complains about this as well. >=20 > Teemu>It now says:".multi-interfaced nodes and provides a solution", as t= he > solution is proposed for both IPv4 and IPv6. OK. > . The document in general makes use of the term "DNS suffix".=A0 It could= be > that I've simply never encountered the term before, but it took me a whil= e > of reading to realize this actually meant "domain name".=A0 I would sugge= st > clarifying this up front someplace, or changing it to "domain name" > throughout. >=20 > Teemu>It was changed to "domain" throughout. However, for section 4.1 (wh= ere > this is introduced) I added further clarification that "domain" is referr= ing > to "DNS domain name suffixes": > -- > ...matching to specific DNS domain name suffixes or reverse (PTR record) = lookup > requests matching to specific network addresses (later referred= as > "domain" and "network"). > -- I still think the use of "suffix" is odd, though it's hard to argue that it= 's technically incorrect. For foobar.nokia.com, I would think "nokia.com" = is the domain name, not a suffix attached to the name "foobar". I'd be mor= e comfortable with calling "foobar" a prefix, but even that doesn't seem ri= ght to me. If you really like the term "suffix", I suggest putting a paragraph somewhe= re early on saying "When we use the term 'DNS suffix', we actually mean a d= omain name that is the root of future queries in common" or something like = that. > . The last paragraph of Section 2.4 is confusing.=A0 It says "After the > interface change[,] a host could have both positive and negative DNS cach= e > entries no longer valid on the new network interface."=A0 Should that > "both.and" be "either.or"?=A0 I'm not clear on how a single node can have= both > positive and negative DNS cache entries no longer valid on the new > interface, unless you mean some of its cache will be positive and wrong a= nd > some of its cache will be negative and wrong (about different names) afte= r > the move.=A0 This should be clarified. >=20 > Teemu> Section 2.2.. It tries to say any cached entry may or may not be > valid after interface change - as you guessed. How about: > -- > A thing worth noting is that network specific IP addresses can cause > problems also for a single-homed node, if the node retains DNS cache duri= ng > movement from one network to another. After the network change, a node ma= y > have both wrong positive and wrong negative entries in its DNS cache.> -- I suggest: It is worth noting is that network specific IP addresses can cause problems also for a single-homed node, if the node retains DNS cache during movement from one network to another. After the network change, a node may have entries in its DNS cache that are no longer correct or appropriate for= its new network position. > . I found it strange to read RFC2119 normative language Section 4.1 which > describes an internal-use algorithm for collecting and organizing data > learned from DHCP and DHCPv6 to build up a set of rules for deciding whic= h > nameserver(s) to use for which queries.=A0 The same sort of thing appeare= d > later in Sections 4.5 and 4.6.=A0 My understanding is that, since DHCP an= d > DHCPv6 are the wire protocols used and this section describes an > internal-use mechanism, these bits of the text shouldn't include any RFC2= 119 > language; there is nothing here that affects interoperability between two > nodes implementing this protocol.=A0 If a node implementing this gets it > wrong, it only hurts itself; the wire protocols don't break.=A0 If this > section were to be separated into its own document, it would be > Informational, not Standards Track.=A0 This isn't a showstopper for me, b= ut I > did find it unusual. >=20 > Teemu>The normative text for this algorithm is there mostly due concerns > that otherwise this option could open a new attack vector. By describing = how > a node MUST handle the information it receives, the risk of attacks shoul= d > be decreased. The normative text is there also so that if a node claims > compliancy to RFC, network operator who provides such options (to build a > system) could expect a node to behave as is described. OK. In that case, I suggest that this be stated either before the normativ= e stuff begins, or along with it, to show how important it is that this be = the way things are done. Another approach would be to spell out the security implications of not pre= cisely following the algorithm later on in Section 10. > . There are a few places in the document, the Introduction and Section 4.= 1 > for example, that talk about PTR lookup requests matching specific IPv6 > prefixes.=A0 However, the abstract mentions IPv4 support, and the mechani= sm is > also described for IPv4.=A0 I suggest making a quick pass through the doc= ument > to be sure it doesn't appear as if IPv6 is the focus and IPv4 was added i= n > as an after-thought. >=20 > Teemu>Well IPv4 was after-thought as I would have settled for IPv6-only b= ut > WG wanted IPv4 option as well:-) I'm afraid I agree with the working group then. :-) > The -04 version should have cleared several > of these "IPv6 focus" issues (by talking about network addresses instead = of > prefixes), but I guess checking again would not hurt. On the other hand, > IPv6 really is the focus here, as multi-interface behavior with IPv4 anyw= ay > is terrible mess due widespread usage of RFC1918 addressed networks (and > that's why I'm secretly hoping DHC WG would say they don't want to use DH= CP > option code for this option and hence this technology must be IPv6- > only:-D. This is also text you might want to add in there, perhaps in a later sectio= n or an appendix, explaining why doing this in IPv4 space is more challengi= ng. Referring to another document that already discusses this is fine as w= ell. > . The normative language in Section 4.1 around DNSSEC seems to be the kin= d > of thing that should be left for local policy.=A0 I can envision environm= ents > where the client isn't doing anything sensitive enough to demand DNSSEC, = so > the first reply it gets from any nameserver it queried is probably fine. > The same sort of thing reappears in Section 4.4. >=20 > Teemu>This document should already allow such local policy. Section 4.4. > describes possibility of "unless the node is specifically configured to d= o > so.". The DNSSEC requirement has been very hard on MIF WG mailing list > discussions in order to fight against creation of new attack vectors, hen= ce > easing that requirement requires restarting of those discussions. See als= o > section 4.4 for cases where DNSSEC is not required - like the option 1:"T= he > server selection option is delivered across a secure, trusted channel." I think the thing that's nagging me the most about 4.1 is this: "Therefore,= a DNSSEC-aware resolver MUST NOT proceed with a reply that cannot be valid= ated using DNSSEC if DNS queries sent to other servers are still pending." = If my node is DNSSEC-aware and connected simultaneously to the public inte= rnet and a corporate VPN, but neither the public nameserver nor the one on = the corporate VPN use DNSSEC, then by this rule my node can't use any reply= at all. It seems to me that ought to be a SHOULD NOT, because this is a c= ase where my resolver can just use whatever replies it gets. It could also be that you're saying you SHOULD NOT use any replies until (a= ) you get a DNSSEC one back or (b) you get all of them back and none of the= m are DNSSEC-protected in which case you can use any of them at your discre= tion. If that's the case, then you should say so. > . In Section 4.2, the paragraph starting "If the OPTION_DNS_SERVER_SELECT > contains." was a little confusing to read.=A0 It says in general that whe= n > learning about DNS servers available, the node can update what it knows b= ut > can't forget what it's learned, however it can ignore things it chooses t= o > ignore.=A0 I found this difficult to follow.=A0 Some expansion of this > paragraph, perhaps with examples, might help. >=20 > Teemu>I wonder if it would be actually wiser just to keep one instance of > the option contents in memory (from most trusted network interface?), and > ensure all legitimate DHCP servers have the same content for the same DNS > server option? You might just keep everything and rank them in decreasing order of trust, = evaluated through some appropriate means (known friendly networks first, se= cured networks second, public networks third), and then search top-to-botto= m when you're preparing to send a query. That's just off the top of my hea= d though; you guys are the experts here. :-) > . Section 4.4 says a node MUST NOT use the feature being described here > unless specifically configured to do so.=A0 That seems odd.=A0 Is the int= ent to > have implementations force this feature off-by-default? >=20 > Teemu>Pretty much so, due security concerns. Please note that other SDOs = or > organizations that create profiles may say that in their environments the > feature shall be on-by-default. Fair enough. It's a minor point, but I would probably be more comfortable = with: Use of OPTION_DNS_SERVER_SELECT is ideal in the following environments, but= SHOULD NOT be enabled by default otherwise: > . I didn't understand this sentence in Section 4.5: "When both options ar= e > received from the same network interface ., the resolver MUST make the > decision which one to prefer based on preferences." >=20 > Teemu>modified to:"...decision which one to prefer based on DNS preferenc= e > field value.". Better? Yes. > . Section 7 says "To ensure nodes' routing . works correctly, network > administrators should also deploy related technologies for that purpose." > Are there any that can be suggested or referenced here? >=20 > Teemu>I actually removed that sentence on -04 as it is probably better to > tie different solution documents together in some other document (like at > draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat ). The reference could > have been to RFC4191 and MIF DHCPv6 route option (at least). Your call; removing it is fine, pointing the reader to a useful technology = to fill that gap is fine too. > . Appendix A is called "Best Current Practice", but the first section sta= rts > out "A possible current practice."=A0 Where's the best one, and why is it > best? >=20 > Teemu>well.. changed title of Appendix A to "Possible alternative practic= es > for DNS server selection". Better? Yes. > Nits: > . In Section 5, the explanation bullets under Figure 7 include two DHCPv6 > replies.=A0 The second one covered "example.com" and a specific IPv6 suff= ix, > but it's not clear that there was no overlap with the first one (i.e., th= e > first one could've said the same thing).=A0 It should be made clear that = they > had disjoint replies. >=20 > Teemu>Ok.. changed to: > --- > 2. The node obtains domain 'domain1.example.com' and IPv6 network > '0.8.b.d.0.1.0.0.2.ip6.arpa' for the new interface 1 from DHCPv6 > server > .... > 5. The node obtains domain 'domain2.example.com' and IPv6 network > information, say '1.8.b.d.0.1.0.0.2.ip6.arpa' for the new > interface 2 from DHCPv6 server > --- > and later in fig 8: > -- > 1. An application makes a request for resolving an FQDN, e.g. > 'private.domain2.example.com' > -- Perfect. > . Appendix A.1 uses the term "hotspot" which is colloquial and might even= be > trademarked.=A0 I suggest "wireless network". >=20 > Teemu>That part was removed at the same time the text talking about leaki= ng > names was removed.. Why was that removed? I thought it was a good point. Good work, thanks for your response! -MSK Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3FE21F8BE8; Wed, 14 Sep 2011 06:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.171 X-Spam-Level: X-Spam-Status: No, score=-3.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 pWgbYCqBUSBO; Wed, 14 Sep 2011 06:53:53 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED4021F8BBE; Wed, 14 Sep 2011 06:53:53 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p8EDtwUO004145; Wed, 14 Sep 2011 16:55:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 16:55:53 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 14 Sep 2011 15:55:43 +0200 Received: from 008-AM1MPN1-032.mgdnok.nokia.com ([169.254.2.143]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0323.007; Wed, 14 Sep 2011 15:55:42 +0200 From: To: Thread-Topic: apps-team review of draft-ietf-mif-dns-server-selection Thread-Index: AcxyrBw6zVCShQsaRQaFoCi5Am4oqAALTEuA Date: Wed, 14 Sep 2011 13:55:41 +0000 Message-ID: <916CE6CF87173740BC8A2CE44309696202573D36@008-AM1MPN1-032.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Company Confidential;Project=None; x-titus-version: 3.3.8.1 x-headerinfofordlp: None x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Io6FujjSfNcXJGUP9WUdfQoJmpfVHi50dPq5KK9wdv8YWMOnlWEAV7vitTS8DUHPOf+v+0rDoqIXDlYBGAkr4aFmlVX72DYkzc7FMyhxe1AE8JaiM8N+owe8T46p+5odYFpcc3S+UERsY5D3pIS96GmVqZGZtQWAUs09Yxm1Ek/ZYVTro9BId1kuOpfCWBge+hJ0ptecrs9ytVuIdhk7jdg+3nvOdW/pcJuz+sJe2aL250googH0+uPDSPjEzpjeNw== x-originating-ip: [10.162.78.119] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0158_01CC72FF.21E75F20" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Sep 2011 13:55:53.0618 (UTC) FILETIME=[04D78720:01CC72E6] X-Nokia-AV: Clean X-Mailman-Approved-At: Wed, 14 Sep 2011 08:20:13 -0700 Cc: apps-ads@tools.ietf.org, mif@ietf.org, apps-review@ietf.org Subject: Re: [apps-review] apps-team review of draft-ietf-mif-dns-server-selection X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 13:53:58 -0000 ------=_NextPart_000_0158_01CC72FF.21E75F20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you very much for your extensive review, I have replied and = commented inline. I cc=92d mif, apps-ads, and apps-review =96 hope it is ok. Completing review of -03 revision was just fine approach, as the -04 was created only to share updates done based on feedback for -03 that was received by yesterday evening my time.=20 I will wait a while for additional input before uploading -05. Best regards, Teemu ------- From: ext Murray S. Kucherawy [mailto:msk@cloudmark.com]=20 Sent: 14. syyskuuta 2011 10:01 To: draft-ietf-mif-dns-server-selection@tools.ietf.org; mif-chairs@tools.ietf.org Cc: apps-review@ietf.org; apps-ads@tools.ietf.org Subject: apps-team review of draft-ietf-mif-dns-server-selection I have been selected as the Applications Area Review Team reviewer for = this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments = you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mif-dns-server-selection-03 Title: Improved DNS Server Selection for Multi-Homed Nodes Reviewer: Murray S. Kucherawy Review Date: September 13, 2011 IETF Last Call Date: N/A (not yet in IETF Last Call) IESG Telechat Date: N/A (not scheduled) Summary: This draft is almost ready for publication as a Standards Track = RFC but has a few issues that should be fixed before publication. NOTE: This is an early review, so please ignore the parts of this boilerplate that sound as though you=92re in IETF Last Call.=A0 Also, = this is a review of the -03 version of the draft.=A0 A new version was published = after I had already completed a good part of my review, so I completed it based = on this version and not the new one.=A0 I haven=92t looked at the diffs = between the two. Major Issues: =95 None. Minor Issues: =95 The IANA Considerations section seems to be a little understated. = =A0I would suggest copying the one from RFC3646 and modifying it accordingly. Teemu>Roger that, I updated my -05 candidate IANA considerations section = to look following (as of now): -- This memo requests IANA to assign two new option codes. First option code is requested to be assigned for DHCPv4 DNS Server Selection option (TBD) from the DHCP option code space defined in section "New DHCP option codes" of RFC 2939. Second option code is requested to be assigned to the DHCPv6 DNS Server Selection option (TBD) from the DHCPv6 option code space defined in section "IANA Considerations" of RFC 3315. -- =95 The use of =93domain=94 in the first paragraph of Section 1 is = ambiguous.=A0 The word =93domain=94 is unfortunately overloaded to mean management domain, = DNS domain, and probably some others, plus the usual dictionary = definition.=A0 I recommend simply saying =93a solution for IPv6.=94=A0 Don=92t be = surprised if a DNS Directorate reviewer complains about this as well. Teemu>It now says:=94=85multi-interfaced nodes and provides a = solution=94, as the solution is proposed for both IPv4 and IPv6. =95 The document in general makes use of the term =93DNS suffix=94.=A0 = It could be that I=92ve simply never encountered the term before, but it took me a = while of reading to realize this actually meant =93domain name=94.=A0 I would = suggest clarifying this up front someplace, or changing it to =93domain name=94 throughout. Teemu>It was changed to =93domain=94 throughout. However, for section = 4.1 (where this is introduced) I added further clarification that =93domain=94 is = referring to =93DNS domain name suffixes=94: -- =85..matching to specific DNS domain name suffixes or reverse (PTR = record) lookup requests matching to specific network addresses (later = referred as "domain" and "network"). -- =95 The last paragraph of Section 2.4 is confusing.=A0 It says =93After = the interface change[,] a host could have both positive and negative DNS = cache entries no longer valid on the new network interface.=94=A0 Should that =93both=85and=94 be =93either=85or=94?=A0 I=92m not clear on how a = single node can have both positive and negative DNS cache entries no longer valid on the new interface, unless you mean some of its cache will be positive and wrong = and some of its cache will be negative and wrong (about different names) = after the move.=A0 This should be clarified. Teemu> Section 2.2.. It tries to say any cached entry may or may not be valid after interface change =96 as you guessed. How about: -- A thing worth noting is that network specific IP addresses can cause problems also for a single-homed node, if the node retains DNS cache = during movement from one network to another. After the network change, a node = may have both wrong positive and wrong negative entries in its DNS cache. -- =95 I found it strange to read RFC2119 normative language Section 4.1 = which describes an internal-use algorithm for collecting and organizing data learned from DHCP and DHCPv6 to build up a set of rules for deciding = which nameserver(s) to use for which queries.=A0 The same sort of thing = appeared later in Sections 4.5 and 4.6.=A0 My understanding is that, since DHCP = and DHCPv6 are the wire protocols used and this section describes an internal-use mechanism, these bits of the text shouldn=92t include any = RFC2119 language; there is nothing here that affects interoperability between = two nodes implementing this protocol.=A0 If a node implementing this gets it wrong, it only hurts itself; the wire protocols don=92t break.=A0 If = this section were to be separated into its own document, it would be Informational, not Standards Track.=A0 This isn=92t a showstopper for = me, but I did find it unusual. Teemu>The normative text for this algorithm is there mostly due concerns that otherwise this option could open a new attack vector. By describing = how a node MUST handle the information it receives, the risk of attacks = should be decreased. The normative text is there also so that if a node claims compliancy to RFC, network operator who provides such options (to build = a system) could expect a node to behave as is described.=20 =95 There are a few places in the document, the Introduction and Section = 4.1 for example, that talk about PTR lookup requests matching specific IPv6 prefixes.=A0 However, the abstract mentions IPv4 support, and the = mechanism is also described for IPv4.=A0 I suggest making a quick pass through the = document to be sure it doesn=92t appear as if IPv6 is the focus and IPv4 was = added in as an after-thought. Teemu>Well IPv4 was after-thought as I would have settled for IPv6-only = but WG wanted IPv4 option as well:-) The -04 version should have cleared = several of these "IPv6 focus" issues (by talking about network addresses instead = of prefixes), but I guess checking again would not hurt. On the other hand, IPv6 really is the focus here, as multi-interface behavior with IPv4 = anyway is terrible mess due widespread usage of RFC1918 addressed networks (and that's why I'm secretly hoping DHC WG would say they don=92t want to use = DHCP option code for this option and hence this technology must be = IPv6-only:-D. =95 The normative language in Section 4.1 around DNSSEC seems to be the = kind of thing that should be left for local policy.=A0 I can envision = environments where the client isn=92t doing anything sensitive enough to demand = DNSSEC, so the first reply it gets from any nameserver it queried is probably = fine.=A0 The same sort of thing reappears in Section 4.4. Teemu>This document should already allow such local policy. Section 4.4. describes possibility of "unless the node is specifically configured to = do so.". The DNSSEC requirement has been very hard on MIF WG mailing list discussions in order to fight against creation of new attack vectors, = hence easing that requirement requires restarting of those discussions. See = also section 4.4 for cases where DNSSEC is not required - like the option = 1:"The server selection option is delivered across a secure, trusted channel." =95 In Section 4.2, the paragraph starting =93If the = OPTION_DNS_SERVER_SELECT contains=85=94 was a little confusing to read.=A0 It says in general = that when learning about DNS servers available, the node can update what it knows = but can=92t forget what it=92s learned, however it can ignore things it = chooses to ignore.=A0 I found this difficult to follow.=A0 Some expansion of this paragraph, perhaps with examples, might help. Teemu>I wonder if it would be actually wiser just to keep one instance = of the option contents in memory (from most trusted network interface?), = and ensure all legitimate DHCP servers have the same content for the same = DNS server option? =95 At the end of Section 4.2, it says =93=85use of generic DHCPv6 = Information Refresh Time Option, as specified in [RFC4242], is envisaged.=94=A0 That = wording is odd; shouldn=92t it be RECOMMENDED?=A0 It=92s too vague otherwise. Teemu>Fine for me, changed on -05 candidate accordingly. =95 Section 4.4 says a node MUST NOT use the feature being described = here unless specifically configured to do so.=A0 That seems odd.=A0 Is the = intent to have implementations force this feature off-by-default? Teemu>Pretty much so, due security concerns. Please note that other SDOs = or organizations that create profiles may say that in their environments = the feature shall be on-by-default. =95 I didn=92t understand this sentence in Section 4.5: =93When both = options are received from the same network interface =85, the resolver MUST make the decision which one to prefer based on preferences.=94 Teemu>modified to:"...decision which one to prefer based on DNS = preference field value.". Better? =95 Section 7 says =93To ensure nodes=92 routing =85 works correctly, = network administrators should also deploy related technologies for that = purpose.=94=A0 Are there any that can be suggested or referenced here? Teemu>I actually removed that sentence on -04 as it is probably better = to tie different solution documents together in some other document (like = at draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat ). The reference could have been to RFC4191 and MIF DHCPv6 route option (at least). =20 =95 Appendix A is called =93Best Current Practice=94, but the first = section starts out =93A possible current practice=85=94=A0 Where=92s the best one, and = why is it best? Teemu>well.. changed title of Appendix A to "Possible alternative = practices for DNS server selection". Better? Nits: =95 There are a few places where I saw RFC2119 words used in = non-normative ways, such as the last sentence of Section 3.1 or the middle of Section = 7.=A0 I would suggest considering alternate words like =93might=94 in place of = =93may=94 specifically to avoid such issues. Teemu>You refer to section 7 comment regarding "are recommended to = avoid..". The section 7 was completely rewritten for -04 and is now using = normative ways. On section 3.1 you refer to "may be considered.."? Changed that to might. I guess the doc needs reading pass to find possible other = instances of this issue... =95 There=92s a discussion point at the end of Section 4.1 that asks = =93What about those DNS servers that instead of a negative answer always return = positive reply with an IP address of some captive portal?=94=A0 I don=92t think = software implementing this specification can determine that via a DHCP query = without other supporting changes to the infrastructure.=A0 I suggest not trying = to tackle this point. Teemu>Thank you for commenting - and also supporting - on this issue. I thought about this yesterday and also decided not trying to tackle this point and removed the note from -04.... Node with DNSSEC implementation would fail on validation on such cases.. but would still have to = continue in order to get to the captive portal.... =95 In Section 4.3, Figure 6, the order of = =93DNS-recusrive-name-server=94 and =93prf=94 in the description should be swapped to match the order in = which they appear in the diagram. Teemu>Changed =95 In Section 5, the explanation bullets under Figure 7 include two = DHCPv6 replies.=A0 The second one covered =93example.com=94 and a specific IPv6 = suffix, but it=92s not clear that there was no overlap with the first one (i.e., = the first one could=92ve said the same thing).=A0 It should be made clear = that they had disjoint replies. Teemu>Ok.. changed to: --- 2. The node obtains domain 'domain1.example.com' and IPv6 network '0.8.b.d.0.1.0.0.2.ip6.arpa' for the new interface 1 from DHCPv6 server .... 5. The node obtains domain 'domain2.example.com' and IPv6 network information, say '1.8.b.d.0.1.0.0.2.ip6.arpa' for the new interface 2 from DHCPv6 server ---=20 and later in fig 8: -- 1. An application makes a request for resolving an FQDN, e.g. 'private.domain2.example.com' -- =95 In several places there are references to =93chapters=94 instead of = =93sections=94 or the =93section=94 reference is not capitalized, which xml2rfc does = for you.=A0 It seems then these are manual references rather than automatic ones, = though the document does claim to have been produced by xml2rfc.=A0=A0 You = might make your life easier by changing them to tags. Teemu>Fixed manually... will try to remember to update to automatic = later:-D =95 Section 10 might be improved by dividing separate topics into their = own subsections.=A0 For example, the first three paragraphs could become = Section 10.1, and the remaining two could go in 10.2 and 10.3. Teemu>I will think about this (now running out of time to do edits while replying) =95 Appendix A.1 uses the term =93hotspot=94 which is colloquial and = might even be trademarked.=A0 I suggest =93wireless network=94. Teemu>That part was removed at the same time the text talking about = leaking names was removed.. =95 The document is in need of a full edit pass with attention to = corrections of English grammar.=20 Teemu>Yep, hopefully by someone who is native English speaker:-) (or otherwise skilled). ------=_NextPart_000_0158_01CC72FF.21E75F20 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOuzCCAzYw ggIeoAMCAQICBDpVqdkwDQYJKoZIhvcNAQEFBQAwKTEOMAwGA1UEChMFTm9raWExFzAVBgNVBAMT Dk5va2lhICBSb290IENBMB4XDTAxMDEwNTExMDUwNVoXDTE2MDEwMjExMDUwNVowKTEOMAwGA1UE ChMFTm9raWExFzAVBgNVBAMTDk5va2lhICBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsrTy8gLmr4LYvp0khVUVHw7ascdl+Cjr+yI5MlZ6J/U6Qsvkiqthgqq8rPcLV0P1 92TfBr27VgKEeCaZe0icS1jC2spM/wRv3j2WxdkKxb9kDJtuCNJaRBqvi5vGTHB15nmEmKuL5f3i rAxeHqPjgS496oWcudzFT1e7Xrc/gWGFYd72+/ykIFXjWOMZv6QpxD8x1hLPyh2YVXRk9U7N7pvm RQNX29g4SCFJY2BBIa5JPlwIF8Nc9IePaC/E/2M4tGMtiOOZlm99EoL7N0hJZtFSvUwdCBud/viH 4DgsKGjNkNKi6pAHc9IaXB6tIykcoYp+L+oe/3+cuEJaCj1EKwIDAQABo2YwZDASBgNVHRMBAf8E CDAGAQH/AgEEMB0GA1UdDgQWBBSNjfefoQ0AITLvqe0iruA79NB9sDAfBgNVHSMEGDAWgBSNjfef oQ0AITLvqe0iruA79NB9sDAOBgNVHQ8BAf8EBAMCAYYwDQYJKoZIhvcNAQEFBQADggEBAIGEPql2 TALyKi/h1J+Mh5XolAtYppcSOLMtBkoA7ZovGBDNvl0VbZs8AAojJqkUoWBB+L6DKyl/jKhNfKcu rWRGRyj7pnbxrKLsI3gmWNWkyo2b60wJwe9fqPD5ZQy3oEiMit9l0Ba6il/k2GqYopUCNMa7mfeb E2LeBy5ChYMiCi97UQSJvAdzEYylTJw8Awc6AiM2Ve5N+XxsmKgNf/2A/5IJ3EZZ+wFRmkI4062A oNU302rqAt0HH88jzoUF4AfYHWl6HpYhGXFbcX44rHINyPmFBRxLYIFJ6ZWUr/mXpL/e6rqFtNWO kV6UoJND7OVZkbLh7F1+lcqXRU8TPBMwggOHMIICb6ADAgECAgRBtbHpMA0GCSqGSIb3DQEBBQUA MCkxDjAMBgNVBAoTBU5va2lhMRcwFQYDVQQDEw5Ob2tpYSAgUm9vdCBDQTAeFw0wNjAzMzAwOTU3 MTFaFw0xNjAxMDIxMTA1MDVaMDMxCzAJBgNVBAYTAkZJMQ4wDAYDVQQKEwVOb2tpYTEUMBIGA1UE AxMLTm9raWEgQkkgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDtFCg3QEjSCg6T IUxoWsNwELh8bBNiUQPCPmg8c2DHQYXWWCSCMb+S0Fvh1qqI1xt+XnzyFq+5eqzGzDj4UaBcG+d9 qxrCFly8sHyoPTryyPrR0EI2UUDWwfS6ojhqgwghRqo8G38TjFusyBtLub/5L6yvWYSOHD+JcB+q VM2fbkArPYK4Ydv8WG/DbHjGn0gKq0zwpVZKI/gCK/QALYvte02NXseqvY9/GOyLtjy3Z8erFv71 KKTq+gxI/7DK55pJf3PoD+kT4kyGm6EF9DTdK4ojMdar17uyX0IOZz/4vkkF0d+60nmnLX63FJPA jUyB0HUNJ32NXDo9UsM38aoNAgMBAAGjgawwgakwDwYDVR0TAQH/BAUwAwEB/zARBgNVHSAECjAI MAYGBFUdIAAwDgYDVR0PAQH/BAQDAgGGMFQGA1UdIwRNMEuAFI2N95+hDQAhMu+p7SKu4Dv00H2w oS2kKzApMQ4wDAYDVQQKEwVOb2tpYTEXMBUGA1UEAxMOTm9raWEgIFJvb3QgQ0GCBDpVqdkwHQYD VR0OBBYEFKcksD7Fg+8EDlB2Sxgy58pW0Sy6MA0GCSqGSIb3DQEBBQUAA4IBAQAC3lEUplDlVNOT Pjz/XFezXx2bV2XbCFindhA3F815Egi55H6/cYezEjoP4QLNEGGl2I3aLvkn5A0T8I4pbiFPhIiu B/frbbGg6k6GjQLe/bFQ8F1mAOOR+GyneKZFPfzaRV0jiIR9QqnMXTf8RvKkCJyFj10MZVsLIy/Y uBkzeP3JhzDhUdtPfwmJN6ZbIhH5uR/2BwAGtgQknb8WX3I4wnhWtMUxB8XmayayYs8qWYeIiVkI FV+sLTkWUWVvvKUjyakBpbAW2vUP84DYsJ8TL1YefNjf/nIOByMcORLuV/1gPjyv00qJbcB59AA+ iXe3zIo8QNcgXG0uPQQFmrGDMIID5DCCAsygAwIBAgIQMH5apak8lEy6LmLlLsJy8TANBgkqhkiG 9w0BAQUFADAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJ IENBMB4XDTExMDkwNjA1NTIwNFoXDTE0MDkwNjA1NTIwNFowVjEOMAwGA1UECgwFTm9raWExDzAN BgNVBAsMBlBlb3BsZTEYMBYGCgmSJomT8ixkAQEMCDEwMDI0Njc2MRkwFwYDVQQDDBBTYXZvbGFp bmVuIFRlZW11MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAshEsmw6Yiz6XWX26oF+I s5fsfE1OfCjOelclmtqCiIgXND5klkNOBs2d4ZGzgD9mN+XnTZnOTh249c2WxPBugf12DCcDmBAJ gL+VuWUJVBTE5NRchm/O8nZnZsRFst+gAC9/Juykh4+EYewZ7QbpnlwW7hNpj8eH+rMr+OZHKzdp KTftgVjmuF4JJ/cPMQUjL8SuGj+zBW6IWPOZdqkEMtf7Pr8kkYbZsh0SgJ0ceRHZ7Uc06mB/y+C1 UnJPxehTTdu8tpCjdzXgBw/H2uuW1J3qdHbCfbuDILql8V8RiZKubcZLhdsD3Jvj8qK0DGWBJa6x p90q5p3pLE8LvAeCgQIDAQABo4HQMIHNMA4GA1UdDwEB/wQEAwIEMDAfBgNVHSMEGDAWgBSnJLA+ xYPvBA5QdksYMufKVtEsujAZBgNVHSAEEjAQMA4GDCsGAQQBXgExBgEHAzA5BgNVHR8EMjAwMC6g LKAqhihodHRwOi8vY3JsLm5va2lhLmNvbS9Ob2tpYSUyMEJJJTIwQ0EuY3JsMCUGA1UdEQQeMByB GnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBQTRzvZsgmQrAGCeuzdHTGAC6Jg UzANBgkqhkiG9w0BAQUFAAOCAQEACmPVsdi07pjK5gDa+W5JlE2C74kVVsB8alBqfioYeR5At2FG B7sua4Dz5H7TJMpZ1jYFeI+zjexD5f+beY2IlV15lMoWD+5e38QlLYjwfe2LAyvdzBKXW0e0U6Bt p78ft4gyVak1X+Db+ebR+FNHUOMNhm+yK3w9sy5ZQzBFusIx4OgxGvcZhyhmd9WjipSTalgPwgqV Ju2aPADCG++OEXmgEWRLsR4yNopkgK4ftVqrN5uUtLs83qdeXTRcNRiET1IOx5zmYFZ6q3gjKIx5 iyuxcDeYas93vVHUcaRRYpsoby5CHq7Z/j/TQhtqO/knWuxLFFiCUgdGKMKrRkg29DCCBAowggLy oAMCAQICEQCBvi+p+bA/dBtBtybwA6YYMA0GCSqGSIb3DQEBBQUAMDMxCzAJBgNVBAYTAkZJMQ4w DAYDVQQKEwVOb2tpYTEUMBIGA1UEAxMLTm9raWEgQkkgQ0EwHhcNMTEwOTA2MDU1MDM0WhcNMTMw OTA1MDU1MDM0WjBWMQ4wDAYDVQQKDAVOb2tpYTEPMA0GA1UECwwGUGVvcGxlMRgwFgYKCZImiZPy LGQBAQwIMTAwMjQ2NzYxGTAXBgNVBAMMEFNhdm9sYWluZW4gVGVlbXUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDFPmbRVwuo52v+h6xnQUqokAx2xsHjmPBniEkzgtgBNJsFi838ATEg 1zsx+VotoJg7hMijcrQfpTAgW6gpLGnlmw5QQswrNK1zleOHb4pA5JguU3WhVKFkAH/6/2EU2k/9 m8Pb/gwP55cYg80R6fRmbdsWKhseXF/1isW/rJcWLmIYDg/rXfo3ixqtT9MroAMiuoXnb0ij1L2d Jj64LDp3Ld8Jo0qZzk3Fj4apo8PBd8eAH6HloVBJkxQcwAnv561A+Xi1GHZ2mafRYJGO+1uBDwyd g/8ybEXXA4MKo8lPKjBebYBUFvz80DBA/Lq74UysXkG23BSulcG4xQSYGlyzAgMBAAGjgfUwgfIw HwYDVR0jBBgwFoAUpySwPsWD7wQOUHZLGDLnylbRLLowGQYDVR0gBBIwEDAOBgwrBgEEAV4BMQYB BgQwOQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5ub2tpYS5jb20vTm9raWElMjBCSSUyMENB LmNybDAjBgNVHSUEHDAaBggrBgEFBQcDAgYEVR0lAAYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgeA MCUGA1UdEQQeMByBGnRlZW11LnNhdm9sYWluZW5Abm9raWEuY29tMB0GA1UdDgQWBBTGhbTJF0EX iagjymQo6GIuSQeRVDANBgkqhkiG9w0BAQUFAAOCAQEAqai6TxZ/BlMHZIhJNPriBPXkQhUlBkGA buJZ5sVm1HIQhWN8elZKjjJdHi1qWEKhMg7yHjEMZsyV8XAZzK0UnOqkpUnt+jnVkNZ9O7/jRtyK f4WUtq5jErc8Hlv4bbGFRHk1T7AuLLE52r1lYOdmoibnQp03QtlDvHUNa68G7jvzThJhieB7U1xh vH3yy0ktaVnWEgAylqf9yIUFjnqau5R6cE1Xo57IYPk/KitX0YF+OigEI/bOQVMi+fze93ZsAOJv /z6g/NGemvUgl5YSdX0uPQK6kEHf/sp/nZyUWWQ7OjtVSqkq2YuYEueQFxTfafl+78GWqgm6W/Bl 32laYzGCAuswggLnAgEBMEgwMzELMAkGA1UEBhMCRkkxDjAMBgNVBAoTBU5va2lhMRQwEgYDVQQD EwtOb2tpYSBCSSBDQQIRAIG+L6n5sD90G0G3JvADphgwCQYFKw4DAhoFAKCCAXgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTEwOTE0MTM1NTM5WjAjBgkqhkiG9w0B CQQxFgQU6x3CPrUmfIoeen1aZAFN046Od/YwVgYJKwYBBAGCNxAEMUkwRzAzMQswCQYDVQQGEwJG STEOMAwGA1UEChMFTm9raWExFDASBgNVBAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLx MFgGCyqGSIb3DQEJEAILMUmgRzAzMQswCQYDVQQGEwJGSTEOMAwGA1UEChMFTm9raWExFDASBgNV BAMTC05va2lhIEJJIENBAhAwflqlqTyUTLouYuUuwnLxMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAFz3c+sQzhunX2YH2E7n 6GyLez7IGR2wrxVmwGtU8JghaFi9qiflnqvox3cZbszdlAW7az+qUzwyGiEl7skvwwPBJ5IVhttw Zxg22zq2OE0IMiNw4fJ4rgOzNXYA8Ebn+sx8/2tF8P39t+KRxOkMZwufBjF0geCrfSrN1hcOg4NM LK9TKeoBvfhrL5isYJfqTr09kUQrMhAnoeXm8BrJJZkeDy5gRy9ULwxSnp2lNjVyyPMGECOXfumY LkPA4OoADvGy+2KaGUSDWrHGG7NtgjfsCl0eU7Jm77aXgLAXmpMLiKSNOdWXY6GRpOpfHbBFswfd mfTE/gLmmuz2yN5582oAAAAAAAA= ------=_NextPart_000_0158_01CC72FF.21E75F20-- Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDAD21F8B70 for ; Tue, 13 Sep 2011 23:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103 X-Spam-Level: X-Spam-Status: No, score=-103 tagged_above=-999 required=5 tests=[AWL=-0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 19JhuSEmZJ5D for ; Tue, 13 Sep 2011 23:59:15 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC3E21F8B54 for ; Tue, 13 Sep 2011 23:59:15 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 14 Sep 2011 00:01:23 -0700 From: "Murray S. Kucherawy" To: "draft-ietf-mif-dns-server-selection@tools.ietf.org" , "mif-chairs@tools.ietf.org" Date: Wed, 14 Sep 2011 00:01:22 -0700 Thread-Topic: apps-team review of draft-ietf-mif-dns-server-selection Thread-Index: AcxyrBw6zVCShQsaRQaFoCi5Am4oqA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F13512DFC2AEXCHC2corpclo_" MIME-Version: 1.0 Cc: "apps-ads@tools.ietf.org" , "apps-review@ietf.org" Subject: [apps-review] apps-team review of draft-ietf-mif-dns-server-selection X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 06:59:20 -0000 --_000_F5833273385BB34F99288B3648C4F06F13512DFC2AEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been selected as the Applications Area Review Team reviewer for this= draft (for background on apps-review, please see http://www.apps.ietf.org/= content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft. Document: draft-ietf-mif-dns-server-selection-03 Title: Improved DNS Server Selection for Multi-Homed Nodes Reviewer: Murray S. Kucherawy Review Date: September 13, 2011 IETF Last Call Date: N/A (not yet in IETF Last Call) IESG Telechat Date: N/A (not scheduled) Summary: This draft is almost ready for publication as a Standards Track RF= C but has a few issues that should be fixed before publication. NOTE: This is an early review, so please ignore the parts of this boilerpla= te that sound as though you're in IETF Last Call. Also, this is a review o= f the -03 version of the draft. A new version was published after I had al= ready completed a good part of my review, so I completed it based on this v= ersion and not the new one. I haven't looked at the diffs between the two. Major Issues: * None. Minor Issues: * The IANA Considerations section seems to be a little understated.= I would suggest copying the one from RFC3646 and modifying it accordingly= . * The use of "domain" in the first paragraph of Section 1 is ambigu= ous. The word "domain" is unfortunately overloaded to mean management doma= in, DNS domain, and probably some others, plus the usual dictionary definit= ion. I recommend simply saying "a solution for IPv6." Don't be surprised = if a DNS Directorate reviewer complains about this as well. * The document in general makes use of the term "DNS suffix". It c= ould be that I've simply never encountered the term before, but it took me = a while of reading to realize this actually meant "domain name". I would s= uggest clarifying this up front someplace, or changing it to "domain name" = throughout. * The last paragraph of Section 2.4 is confusing. It says "After t= he interface change[,] a host could have both positive and negative DNS cac= he entries no longer valid on the new network interface." Should that "bot= h...and" be "either...or"? I'm not clear on how a single node can have bot= h positive and negative DNS cache entries no longer valid on the new interf= ace, unless you mean some of its cache will be positive and wrong and some = of its cache will be negative and wrong (about different names) after the m= ove. This should be clarified. * I found it strange to read RFC2119 normative language Section 4.1= which describes an internal-use algorithm for collecting and organizing da= ta learned from DHCP and DHCPv6 to build up a set of rules for deciding whi= ch nameserver(s) to use for which queries. The same sort of thing appeared= later in Sections 4.5 and 4.6. My understanding is that, since DHCP and D= HCPv6 are the wire protocols used and this section describes an internal-us= e mechanism, these bits of the text shouldn't include any RFC2119 language;= there is nothing here that affects interoperability between two nodes impl= ementing this protocol. If a node implementing this gets it wrong, it only= hurts itself; the wire protocols don't break. If this section were to be = separated into its own document, it would be Informational, not Standards T= rack. This isn't a showstopper for me, but I did find it unusual. * There are a few places in the document, the Introduction and Sect= ion 4.1 for example, that talk about PTR lookup requests matching specific = IPv6 prefixes. However, the abstract mentions IPv4 support, and the mechan= ism is also described for IPv4. I suggest making a quick pass through the = document to be sure it doesn't appear as if IPv6 is the focus and IPv4 was = added in as an after-thought. * The normative language in Section 4.1 around DNSSEC seems to be t= he kind of thing that should be left for local policy. I can envision envi= ronments where the client isn't doing anything sensitive enough to demand D= NSSEC, so the first reply it gets from any nameserver it queried is probabl= y fine. The same sort of thing reappears in Section 4.4. * In Section 4.2, the paragraph starting "If the OPTION_DNS_SERVER_= SELECT contains..." was a little confusing to read. It says in general tha= t when learning about DNS servers available, the node can update what it kn= ows but can't forget what it's learned, however it can ignore things it cho= oses to ignore. I found this difficult to follow. Some expansion of this = paragraph, perhaps with examples, might help. * At the end of Section 4.2, it says "...use of generic DHCPv6 Info= rmation Refresh Time Option, as specified in [RFC4242], is envisaged." Tha= t wording is odd; shouldn't it be RECOMMENDED? It's too vague otherwise. * Section 4.4 says a node MUST NOT use the feature being described = here unless specifically configured to do so. That seems odd. Is the inte= nt to have implementations force this feature off-by-default? * I didn't understand this sentence in Section 4.5: "When both opti= ons are received from the same network interface ..., the resolver MUST mak= e the decision which one to prefer based on preferences." * Section 7 says "To ensure nodes' routing ... works correctly, net= work administrators should also deploy related technologies for that purpos= e." Are there any that can be suggested or referenced here? * Appendix A is called "Best Current Practice", but the first secti= on starts out "A possible current practice..." Where's the best one, and w= hy is it best? Nits: * There are a few places where I saw RFC2119 words used in non-norm= ative ways, such as the last sentence of Section 3.1 or the middle of Secti= on 7. I would suggest considering alternate words like "might" in place of= "may" specifically to avoid such issues. * There's a discussion point at the end of Section 4.1 that asks "W= hat about those DNS servers that instead of a negative answer always return= positive reply with an IP address of some captive portal?" I don't think = software implementing this specification can determine that via a DHCP quer= y without other supporting changes to the infrastructure. I suggest not tr= ying to tackle this point. * In Section 4.3, Figure 6, the order of "DNS-recusrive-name-server= " and "prf" in the description should be swapped to match the order in whic= h they appear in the diagram. * In Section 5, the explanation bullets under Figure 7 include two = DHCPv6 replies. The second one covered "example.com" and a specific IPv6 s= uffix, but it's not clear that there was no overlap with the first one (i.e= ., the first one could've said the same thing). It should be made clear th= at they had disjoint replies. * In several places there are references to "chapters" instead of "= sections" or the "section" reference is not capitalized, which xml2rfc does= for you. It seems then these are manual references rather than automatic = ones, though the document does claim to have been produced by xml2rfc. Yo= u might make your life easier by changing them to tags. * Section 10 might be improved by dividing separate topics into the= ir own subsections. For example, the first three paragraphs could become S= ection 10.1, and the remaining two could go in 10.2 and 10.3. * Appendix A.1 uses the term "hotspot" which is colloquial and migh= t even be trademarked. I suggest "wireless network". * The document is in need of a full edit pass with attention to cor= rections of English grammar. --_000_F5833273385BB34F99288B3648C4F06F13512DFC2AEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have been sele= cted as the Applications Area Review Team reviewer for this draft (for back= ground on apps-review, please see http://www.apps.ietf.org/content/applicatio= ns-area-review-team).


Please res= olve these comments along with any other Last Call comments you may receive= . Please wait for direction from your document shepherd or AD before postin= g a new version of the draft.


Docume= nt: draft-ietf-mif-dns-server-selection-03
Title: Improved DNS Server Se= lection for Multi-Homed Nodes
Reviewer: Murray S. Kucherawy
Review Da= te: September 13, 2011
IETF Last Call Date: N/A (not yet in IETF Last Ca= ll)
IESG Telechat Date: N/A (not scheduled)

Summary: This draft is almost ready for publication as a Sta= ndards Track RFC but has a few issues that should be fixed before publicati= on.


NOTE: This is an early review, s= o please ignore the parts of this boilerplate that sound as though you̵= 7;re in IETF Last Call.  Also, this is a review of the -03 version of = the draft.  A new version was published after I had already completed = a good part of my review, so I completed it based on this version and not t= he new one.  I haven’t looked at the diffs between the two.=


Major Issues:

·  &nb= sp;      None.=


Minor Issues:

·  &nb= sp;      The IANA C= onsiderations section seems to be a little understated.  I would sugge= st copying the one from RFC3646 and modifying it accordingly.

·&= nbsp;        The use of “domain” in the first paragraph of Section 1 is = ambiguous.  The word “domain” is unfortunately overloaded = to mean management domain, DNS domain, and probably some others, plus the u= sual dictionary definition.  I recommend simply saying “a soluti= on for IPv6.”  Don’t be surprised if a DNS Directorate rev= iewer complains about this as well.

&middo= t;    &nbs= p;    The document in general= makes use of the term “DNS suffix”.  It could be that I&#= 8217;ve simply never encountered the term before, but it took me a while of= reading to realize this actually meant “domain name”.  I = would suggest clarifying this up front someplace, or changing it to “= domain name” throughout.

·     &nb= sp;   The last paragraph of Sectio= n 2.4 is confusing.  It says “After the interface change[,] a ho= st could have both positive and negative DNS cache entries no longer valid = on the new network interface.”  Should that “both…an= d” be “either…or”?  I’m not clear on how= a single node can have both positive and negative DNS cache entries no lon= ger valid on the new interface, unless you mean some of its cache will be p= ositive and wrong and some of its cache will be negative and wrong (about d= ifferent names) after the move.  This should be clarified.<= /p>

·=          I found it strange to read RFC2119 normative language Section 4.1 whic= h describes an internal-use algorithm for collecting and organizing data le= arned from DHCP and DHCPv6 to build up a set of rules for deciding which na= meserver(s) to use for which queries.  The same sort of thing appeared= later in Sections 4.5 and 4.6.  My understanding is that, since DHCP = and DHCPv6 are the wire protocols used and this section describes an intern= al-use mechanism, these bits of the text shouldn’t include any RFC211= 9 language; there is nothing here that affects interoperability between two= nodes implementing this protocol.  If a node implementing this gets i= t wrong, it only hurts itself; the wire protocols don’t break.  = If this section were to be separated into its own document, it would be Inf= ormational, not Standards Track.  This isn’t a showstopper for m= e, but I did find it unusual.

·     &nbs= p;   There are a few places in the= document, the Introduction and Section 4.1 for example, that talk about PT= R lookup requests matching specific IPv6 prefixes.  However, the abstr= act mentions IPv4 support, and the mechanism is also described for IPv4.&nb= sp; I suggest making a quick pass through the document to be sure it doesn&= #8217;t appear as if IPv6 is the focus and IPv4 was added in as an after-th= ought.

·         <= /span>The normative language in Section 4.1 around DNSSEC = seems to be the kind of thing that should be left for local policy.  I= can envision environments where the client isn’t doing anything sens= itive enough to demand DNSSEC, so the first reply it gets from any nameserv= er it queried is probably fine.  The same sort of thing reappears in S= ection 4.4.

·         In Section 4.2, the paragraph starting “I= f the OPTION_DNS_SERVER_SELECT contains…” was a little confusin= g to read.  It says in general that when learning about DNS servers av= ailable, the node can update what it knows but can’t forget what it&#= 8217;s learned, however it can ignore things it chooses to ignore.  I = found this difficult to follow.  Some expansion of this paragraph, per= haps with examples, might help.

·     &n= bsp;   At the end of Section 4.2, = it says “…use of generic DHCPv6 Information Refresh Time Option= , as specified in [RFC4242], is envisaged.”  That wording is odd= ; shouldn’t it be RECOMMENDED?  It’s too vague otherwise.<= o:p>

·         <= /span>Section 4.4 says a node MUST NOT use the feature being desc= ribed here unless specifically configured to do so.  That seems odd.&n= bsp; Is the intent to have implementations force this feature off-by-defaul= t?

·         I didn’t understand this sentence in Section 4.5: = “When both options are received from the same network interface ̷= 0;, the resolver MUST make the decision which one to prefer based on prefer= ences.”

·         <= /span>Section 7 says “To ensure nodes’ = routing … works correctly, network administrators should also deploy = related technologies for that purpose.”  Are there any that can = be suggested or referenced here?

<= span style=3D'font-family:Symbol'>·<= span style=3D'font:7.0pt "Times New Roman"'>     &= nbsp;   Appendix A is called ̶= 0;Best Current Practice”, but the first section starts out “A p= ossible current practice…”  Where’s the best one, an= d why is it best?

 

<= p class=3DMsoNormal>Nits:

·      =    There are a few places where I = saw RFC2119 words used in non-normative ways, such as the last sentence of = Section 3.1 or the middle of Section 7.  I would suggest considering a= lternate words like “might” in place of “may” speci= fically to avoid such issues.

·     &nbs= p;   There’s a discussion po= int at the end of Section 4.1 that asks “What about those DNS servers= that instead of a negative answer always return positive reply with an IP = address of some captive portal?”  I don’t think software i= mplementing this specification can determine that via a DHCP query without = other supporting changes to the infrastructure.  I suggest not trying = to tackle this point.

·       = ;  In Section 4.3, Figure 6, the order = of “DNS-recusrive-name-server” and “prf” in the des= cription should be swapped to match the order in which they appear in the d= iagram.

·         = In Section 5, the explanation bullets under Figure = 7 include two DHCPv6 replies.  The second one covered “example.c= om” and a specific IPv6 suffix, but it’s not clear that there w= as no overlap with the first one (i.e., the first one could’ve said t= he same thing).  It should be made clear that they had disjoint replie= s.

·         In several places there are references to “chapter= s” instead of “sections” or the “section” ref= erence is not capitalized, which xml2rfc does for you.  It seems then = these are manual references rather than automatic ones, though the document= does claim to have been produced by xml2rfc.   You might make yo= ur life easier by changing them to <xref…> tags.

=

·&= nbsp;        Section 10 might be improved by dividing separate topics into their own= subsections.  For example, the first three paragraphs could become Se= ction 10.1, and the remaining two could go in 10.2 and 10.3.

=

·&= nbsp;        Appendix A.1 uses the term “hotspot” which is colloquial an= d might even be trademarked.  I suggest “wireless network”= .

·         The document is in need of a full edit pass with attentio= n to corrections of English grammar.

= --_000_F5833273385BB34F99288B3648C4F06F13512DFC2AEXCHC2corpclo_-- Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BB311E80D9 for ; Tue, 13 Sep 2011 12:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] 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 MnJ59QdaZJpd for ; Tue, 13 Sep 2011 12:19:25 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id B0A5511E80D3 for ; Tue, 13 Sep 2011 12:19:25 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id B7D271168087; Tue, 13 Sep 2011 20:21:30 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAFFqWCwNkxj; Tue, 13 Sep 2011 20:21:28 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id BDDEB1168067; Tue, 13 Sep 2011 20:21:28 +0100 (BST) References: <6.2.5.6.2.20110913084700.07c39de8@elandnews.com> In-Reply-To: <6.2.5.6.2.20110913084700.07c39de8@elandnews.com> MIME-Version: 1.0 Message-Id: <25236.1315941688.780050@puncture> Date: Tue, 13 Sep 2011 20:21:28 +0100 From: Dave Cridland To: SM , Apps Area Review List Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [apps-review] Request for review: draft-ietf-tsvwg-sctpsocket-31 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 19:19:26 -0000 On Tue Sep 13 16:50:31 2011, SM wrote: > Could you please review draft-ietf-tsvwg-sctpsocket-31 before > September 21? Ack. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9522921F8B40 for ; Tue, 13 Sep 2011 11:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 gNhXPwWuKnJs for ; Tue, 13 Sep 2011 11:07:55 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB5121F8B21 for ; Tue, 13 Sep 2011 11:07:55 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.177]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8DI9sqT016432; Tue, 13 Sep 2011 11:10:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1315937402; bh=9eXcmOv7J7fATTMDQNJ+yfMJs+o=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=HqUZDsvoLIBjYdDjN/ca5cfMjCVggPb2UDh+PQ1dMfzuT/z5AX+9NE9zPI+RYa5H3 1hoHb8CwqLZaq17sQtovgsGFtGuvmtsi7Q5jR2SUWnLG2dJyOsQKi/sAmdVArUB/ph Ed3YPDm4hQn0z3h/+QcEOPQL0RyRLvBTiw/W6UdI= Message-Id: <6.2.5.6.2.20110913110834.0a015d20@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Sep 2011 11:09:42 -0700 To: Tim Bray From: SM In-Reply-To: <6.2.5.6.2.20110913083721.0a1b6598@elandnews.com> References: <6.2.5.6.2.20110913083721.0a1b6598@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-ietf-ecrit-lost-sync-12 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 18:07:56 -0000 Hi Tim, Could you please take over the review draft-ietf-ecrit-lost-sync-12 before September 21? You can find information about the author and WG in the datatracker ( https://datatracker.ietf.org/ ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the authors, the IESG, the WG Chairs and document shepherd, if applicable. The subject of the email when submitting the review should be "apps-team review of" ID-name. If I don't receive an acknowledgement from you within two days, I'll send you a reminder before reassigning the review. Thanks, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A16221F8A80 for ; Tue, 13 Sep 2011 10:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 OYM1Uxqm6i32 for ; Tue, 13 Sep 2011 10:41:27 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 11AA821F8A69 for ; Tue, 13 Sep 2011 10:41:26 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.177]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8DHhPNg015271; Tue, 13 Sep 2011 10:43:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1315935813; bh=jnhWvZniYIaPJcsA/QxFbH3bqhc=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=HQIkNc7GsYlwA2LzjkoiXal/JytYPSX9H1q2kQe187Z9YmlYNMtrUJHNoi3Pr+QxT viYj54oiiLvTYmlzINP2c8dHwOzLFOm0fLMIeA/C3VB255Wlv2mFdt+PDuhkAqUuIp aWIvlhhdnvMQ47RSwlKfEtAHTIUM5ljJvtBR+Jkk= Message-Id: <6.2.5.6.2.20110913104219.07c70298@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Sep 2011 10:43:22 -0700 To: Peter Saint-Andre From: SM In-Reply-To: <4E6F93B2.8060609@stpeter.im> References: <6.2.5.6.2.20110913083721.0a1b6598@elandnews.com> <4E6F93B2.8060609@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-ietf-ecrit-lost-sync-12 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 17:41:30 -0000 Hi Peter, At 10:32 13-09-2011, Peter Saint-Andre wrote: >Carsten has been extremely busy and might not be available right now to >review this specification. Thanks, I'll reassign the review to someone else. Best regards, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B86421F8C4C for ; Tue, 13 Sep 2011 10:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 oBhGhl5goQrP for ; Tue, 13 Sep 2011 10:30:28 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CEC6921F8C46 for ; Tue, 13 Sep 2011 10:30:28 -0700 (PDT) Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0CE7A41A0B; Tue, 13 Sep 2011 11:35:48 -0600 (MDT) Message-ID: <4E6F93B2.8060609@stpeter.im> Date: Tue, 13 Sep 2011 11:32:34 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20110913083721.0a1b6598@elandnews.com> In-Reply-To: <6.2.5.6.2.20110913083721.0a1b6598@elandnews.com> X-Enigmail-Version: 1.3.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-ietf-ecrit-lost-sync-12 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 17:30:29 -0000 Carsten has been extremely busy and might not be available right now to review this specification. On 9/13/11 9:42 AM, SM wrote: > Hi Carsten, > > Could you please review draft-ietf-ecrit-lost-sync-12 before September 21? > > You can find information about the author and WG in the datatracker ( > https://datatracker.ietf.org/ ). Some previous reviews from the > Apps-review Team are accessible at > http://www.apps.ietf.org/content/apps-review-template > > The review should be sent to apps-discuss, the authors, the IESG, the WG > Chairs and document shepherd, if applicable. > > The subject of the email when submitting the review should be "apps-team > review of" ID-name. > > If I don't receive an acknowledgement from you within two days, I'll > send you a reminder before reassigning the review. > > Best regards, > -sm > > _______________________________________________ > apps-review mailing list > apps-review@ietf.org > https://www.ietf.org/mailman/listinfo/apps-review Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF6321F8CA7 for ; Tue, 13 Sep 2011 09:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.007 X-Spam-Level: X-Spam-Status: No, score=-103.007 tagged_above=-999 required=5 tests=[AWL=-0.408, 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 Qk6-sQEG65l1 for ; Tue, 13 Sep 2011 09:34:36 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 99B6D21F8BA0 for ; Tue, 13 Sep 2011 09:34:36 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 13 Sep 2011 09:36:42 -0700 From: "Murray S. Kucherawy" To: SM Date: Tue, 13 Sep 2011 09:36:41 -0700 Thread-Topic: Request for review: draft-ietf-mif-dns-server-selection-03 Thread-Index: AcxyLdwBvHe6WpF4Q2esCZW2t7bMKwABWybA Message-ID: References: <6.2.5.6.2.20110913084456.07c73ed0@elandnews.com> In-Reply-To: <6.2.5.6.2.20110913084456.07c73ed0@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-review@ietf.org" Subject: Re: [apps-review] Request for review: draft-ietf-mif-dns-server-selection-03 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 16:34:37 -0000 > -----Original Message----- > From: SM [mailto:sm+ietf@elandsys.com] > Sent: Tuesday, September 13, 2011 8:47 AM > To: Murray S. Kucherawy > Cc: apps-review@ietf.org > Subject: Request for review: draft-ietf-mif-dns-server-selection-03 >=20 > Hi Murray, >=20 > Could you please review draft-ietf-mif-dns-server-selection-03 before > September 21? Wilco. Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1135621F8C8A for ; Tue, 13 Sep 2011 09:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 CO3U20iWR25q for ; Tue, 13 Sep 2011 09:27:55 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2126B21F8CAB for ; Tue, 13 Sep 2011 09:27:55 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.4]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8DFunWM006272; Tue, 13 Sep 2011 08:57:06 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1315929428; bh=Vpm4Qul8WKgMyTiZJjziDUHvbeE=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=E4nhRucG7+CJ2YWv/dYN3J2DxFeFWM6p4Fed+7rgnpHz+5NbP/MHadCCAlA4H7OdN n/dLVVNaHr4C7NkJ2MqOcLB3j16kZ0n9cIjzM9GiBjDfHtoH4yPyCvmt/DXdMJpn2X F1V7HfX0zKDqGewUEhIfcYaQhK/PoTF6aCOTOBvw= Message-Id: <6.2.5.6.2.20110913084700.07c39de8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Sep 2011 08:50:31 -0700 To: Dave Cridland From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-ietf-tsvwg-sctpsocket-31 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 16:27:59 -0000 Hi Dave, Could you please review draft-ietf-tsvwg-sctpsocket-31 before September 21? You can find information about the author and WG in the datatracker ( https://datatracker.ietf.org/ ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the authors, the IESG, the WG Chairs and document shepherd, if applicable. The subject of the email when submitting the review should be "apps-team review of" ID-name. If I don't receive an acknowledgement from you within two days, I'll send you a reminder before reassigning the review. Best regards, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2142D21F8CAB for ; Tue, 13 Sep 2011 09:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 oRqf6-9HlA5s for ; Tue, 13 Sep 2011 09:27:55 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC6E21F8CB5 for ; Tue, 13 Sep 2011 09:27:55 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.4]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8DFunWI006272; Tue, 13 Sep 2011 08:57:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1315929422; bh=i/0rJZn0QFAvtZ5djjuwfhQyT5I=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=UqohcfVQEc+O4INcPpbsfa4+cs167fGc5yL3GFSs0PLzMPPne+4xbafmLB5QgOFl/ OZiqIC1qkA44eOPssM9uqtMyxmE4oNTmyMEAjAH4ObLYjCkpyXMkLwo5QB9OlO1BCO 2gKkHDwYO4sXxuAgciQ1n7Vpj1fYM5911RyR0BOc= Message-Id: <6.2.5.6.2.20110913084232.07c6fd78@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Sep 2011 08:44:53 -0700 To: Barry Leiba From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-ietf-sidr-ghostbusters-09 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 16:27:59 -0000 Hi Barry, Could you please review draft-ietf-sidr-ghostbusters-09 before September 21? You can find information about the author and WG in the datatracker ( https://datatracker.ietf.org/ ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the authors, the IESG, the WG Chairs and document shepherd, if applicable. The subject of the email when submitting the review should be "apps-team review of" ID-name. If I don't receive an acknowledgement from you within two days, I'll send you a reminder before reassigning the review. Best regards, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309DD21F8CB5 for ; Tue, 13 Sep 2011 09:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 eLWYaFU4MHIS for ; Tue, 13 Sep 2011 09:27:55 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5D65721F8CBA for ; Tue, 13 Sep 2011 09:27:55 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.4]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8DFunWK006272; Tue, 13 Sep 2011 08:57:03 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1315929425; bh=NUq4gJLHfRt1n8eQU/6fbfQ8jvo=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=I0ERoPv9/Bg8pZmnPjCOvwjvOH7qOYrKL+p9eRwfrRS11yjLgMB1S8JKWycOykbMj 3gpqXNHOnQfmCSajJgo8qT4JHQGf5W/o1Y4lwPF1tXCMLXrUS3zsbIh7TUPAGZcRyj ZhmSl078nDLo7mfi6lvj4G2+nTwX+09nrBtzU2zA= Message-Id: <6.2.5.6.2.20110913084456.07c73ed0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Sep 2011 08:46:57 -0700 To: "Murray S. Kucherawy" From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-ietf-mif-dns-server-selection-03 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 16:27:59 -0000 Hi Murray, Could you please review draft-ietf-mif-dns-server-selection-03 before September 21? You can find information about the author and WG in the datatracker ( https://datatracker.ietf.org/ ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the authors, the IESG, the WG Chairs and document shepherd, if applicable. The subject of the email when submitting the review should be "apps-team review of" ID-name. If I don't receive an acknowledgement from you within two days, I'll send you a reminder before reassigning the review. Best regards, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BFC21F8CC2 for ; Tue, 13 Sep 2011 09:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 kAs+RabP-1uN for ; Tue, 13 Sep 2011 09:27:55 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 09A7E21F8C8A for ; Tue, 13 Sep 2011 09:27:53 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.4]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8DFunWO006272; Tue, 13 Sep 2011 08:57:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1315929431; bh=u1E6+RBgYdbRAqNPzSoFwYWX5VU=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=1bCS7RYTExWnTpfP76C5Sbv5+kCJOqQvM+tfB/ltDrRJ/WnPMI17uV3icQb0T05kr XG6qH1LlkS9zPKuW6WeiutmyA6kXOoUIckDtDA6pZnBtvwQOkUg1boeLd7RPoefzuU Al5SOZDvTzRU7nFIV+2yy3WhykCGeFWEF5MkT3Us= Message-Id: <6.2.5.6.2.20110913085140.07c39f30@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Sep 2011 08:55:15 -0700 To: Ted Hardie From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-ietf-alto-reqs-11 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 16:27:58 -0000 Hi Ted, Could you please review draft-ietf-alto-reqs-11 before September 21? You can find information about the author and WG in the datatracker ( https://datatracker.ietf.org/ ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the authors, the IESG, the WG Chairs and document shepherd, if applicable. The subject of the email when submitting the review should be "apps-team review of" ID-name. If I don't receive an acknowledgement from you within two days, I'll send you a reminder before reassigning the review. Best regards, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A253521F8C8A for ; Tue, 13 Sep 2011 09:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] 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 0AwFnCjwk+Qk for ; Tue, 13 Sep 2011 09:27:32 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E073021F8C86 for ; Tue, 13 Sep 2011 09:27:31 -0700 (PDT) Received: by yxt33 with SMTP id 33so684475yxt.31 for ; Tue, 13 Sep 2011 09:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0xpxbpe7lbNNsOkB+NflJ08xNhvTvC5YIIEoT3+tZDo=; b=Qx1gFVQTy8kZnzzDvmL8hFMPcjs0eaZvqevWbrbj7188yhAeiWM1DgoUy/eonlN2QD hmxasa7Xsi83J0lOKgI78GnF6m1YhHb4yMbXdYfXybdr410F5gfVoWCvp1vH3BhTg+7b +DqHv55+KBxn6HlmdMU1RMDVSN5ngxirJ91mM= MIME-Version: 1.0 Received: by 10.236.175.228 with SMTP id z64mr15909296yhl.2.1315931377080; Tue, 13 Sep 2011 09:29:37 -0700 (PDT) Received: by 10.236.110.174 with HTTP; Tue, 13 Sep 2011 09:29:37 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20110913085140.07c39f30@elandnews.com> References: <6.2.5.6.2.20110913085140.07c39f30@elandnews.com> Date: Tue, 13 Sep 2011 09:29:37 -0700 Message-ID: From: Ted Hardie To: SM Content-Type: multipart/alternative; boundary=20cf303f67c04797f004acd5261f Cc: apps-review@ietf.org Subject: Re: [apps-review] Request for review: draft-ietf-alto-reqs-11 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 16:27:32 -0000 --20cf303f67c04797f004acd5261f Content-Type: text/plain; charset=ISO-8859-1 Okay, will do. Ted On Tue, Sep 13, 2011 at 8:55 AM, SM wrote: > Hi Ted, > > Could you please review draft-ietf-alto-reqs-11 before September 21? > > You can find information about the author and WG in the datatracker ( > https://datatracker.ietf.org/ ). Some previous reviews from the > Apps-review Team are accessible at http://www.apps.ietf.org/** > content/apps-review-template > > The review should be sent to apps-discuss, the authors, the IESG, the WG > Chairs and document shepherd, if applicable. > > The subject of the email when submitting the review should be "apps-team > review of" ID-name. > > If I don't receive an acknowledgement from you within two days, I'll send > you a reminder before reassigning the review. > > Best regards, > -sm > > --20cf303f67c04797f004acd5261f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Okay, will do.

Ted

On = Tue, Sep 13, 2011 at 8:55 AM, SM <sm+ietf@elandsys.com> wrote:
Hi Ted,

Could you please review draft-ietf-alto-reqs-11 before September 21?

You can find information about the author and WG in the datatracker ( https://datatracker.= ietf.org/ ). =A0Some previous reviews from the Apps-review Team are acc= essible at http://www.apps.ietf.org/content/apps-review-tem= plate

The review should be sent to apps-discuss, the authors, the IESG, the WG Ch= airs and document shepherd, if applicable.

The subject of the email when submitting the review should be "apps-te= am review of" ID-name.

If I don't receive an acknowledgement from you within two days, I'l= l send you a reminder before reassigning the review.

Best regards,
-sm


--20cf303f67c04797f004acd5261f-- Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160CB21F8B68 for ; Tue, 13 Sep 2011 08:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 mx5334t30pN0 for ; Tue, 13 Sep 2011 08:54:55 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5028F21F8B4F for ; Tue, 13 Sep 2011 08:54:55 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.4]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8DFunWE006272; Tue, 13 Sep 2011 08:56:54 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1315929416; bh=0JjHnAoJ+2kad8JwKgdzqBaDpm0=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=FWK2mGp1o+FinVjbUh8vucZ3ap8JJ8zlkDTtGV7rFqWncR8Xl3AvG/qFUF/LinHUV KXzYKRKSIVAp7wnT5G+VQYkCE9xR6SZPATA2dNIYZ79MAgDGQS0snhRtXNsUq2rkbo 8GvfePwANgmzRy/bO171gs95OIr0l/7xqWnWuoSc= Message-Id: <6.2.5.6.2.20110913082542.0a1b6970@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Sep 2011 08:37:18 -0700 To: Xiaodong Lee From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-ietf-behave-v4v6-bih-06 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 15:55:00 -0000 Hi Xiaodong, Could you please review draft-ietf-behave-v4v6-bih-06 before September 21? You can find information about the author and WG in the datatracker ( https://datatracker.ietf.org/ ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the authors, the IESG, the WG Chairs and document shepherd, if applicable. The subject of the email when submitting the review should be "apps-team review of" ID-name. If I don't receive an acknowledgement from you within two days, I'll send you a reminder before reassigning the review. Best regards, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E464321F8B61 for ; Tue, 13 Sep 2011 08:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 vpJu9H5hu65s for ; Tue, 13 Sep 2011 08:54:55 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by ietfa.amsl.com (Postfix) with ESMTP id 19F9721F8B55 for ; Tue, 13 Sep 2011 08:54:54 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.4]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id p8DFunWG006272; Tue, 13 Sep 2011 08:56:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1315929419; bh=w5hGjUb2x2iV1Z5J/VUvi3TSCOk=; h=Message-Id:Date:To:From:Subject:Cc:Mime-Version:Content-Type; b=Yy8QxvyBM5fV6O5OrnPtAzBaukbU/8Ny14cjfwf2tFoMprsaPyU2Q+OPDZYZ3Wuu5 /GOgEEkAFRIwXEnqpvD9YhacJwPDmSlOMKQ+O9rkkibeLYGNWn+23lM/i9DNTQqbyp WMba0akLWAtfxBuKGkBSji4YYCN6VhjOnPNsProc= Message-Id: <6.2.5.6.2.20110913083721.0a1b6598@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Sep 2011 08:42:29 -0700 To: Carsten Bormann From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-review@ietf.org Subject: [apps-review] Request for review: draft-ietf-ecrit-lost-sync-12 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 15:55:00 -0000 Hi Carsten, Could you please review draft-ietf-ecrit-lost-sync-12 before September 21? You can find information about the author and WG in the datatracker ( https://datatracker.ietf.org/ ). Some previous reviews from the Apps-review Team are accessible at http://www.apps.ietf.org/content/apps-review-template The review should be sent to apps-discuss, the authors, the IESG, the WG Chairs and document shepherd, if applicable. The subject of the email when submitting the review should be "apps-team review of" ID-name. If I don't receive an acknowledgement from you within two days, I'll send you a reminder before reassigning the review. Best regards, -sm Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BC721F8ABD for ; Thu, 8 Sep 2011 09:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.012 X-Spam-Level: X-Spam-Status: No, score=-103.012 tagged_above=-999 required=5 tests=[AWL=-0.413, 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 MBPHTlg4zzEP for ; Thu, 8 Sep 2011 09:19:35 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 23DF521F886A for ; Thu, 8 Sep 2011 09:19:35 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 8 Sep 2011 09:21:27 -0700 From: "Murray S. Kucherawy" To: "dcrocker@bbiw.net" Date: Thu, 8 Sep 2011 09:21:25 -0700 Thread-Topic: Review of -- draft-ietf-appsawg-rfc3462bis-00 Thread-Index: AcxuKAHREQdjisRPT4WAQ+3Ioadd1QAGthjw Message-ID: References: <4E68BD97.8050601@dcrocker.net> In-Reply-To: <4E68BD97.8050601@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Apps Review Subject: Re: [apps-review] Review of -- draft-ietf-appsawg-rfc3462bis-00 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 16:19:35 -0000 > -----Original Message----- > From: Dave CROCKER [mailto:dhc@dcrocker.net] > Sent: Thursday, September 08, 2011 6:05 AM > To: Murray S. Kucherawy > Cc: Apps Review > Subject: Review of -- draft-ietf-appsawg-rfc3462bis-00 >=20 > Minor Issues: >=20 > Appendix A (Document History) needs a note to the RFC Editor to remov= e the > section before publishing. Fixed. > Nits: >=20 > The document repairs non-normative usage of normative vocabulary, to > eliminate confusion. It also changes normative vocabulary to be upper ca= se, to > aid detection. However it appears that some of these changes were > missed: >=20 >=20 > > 3. The multipart/report Media Type > ... > > generated, for a human reader who may not have a user agent >=20 > may -> might Fixed. > > report. The text in the first section may be in any MIME >=20 > may -> MAY {{ I believe. /d }} I went with "can"; maybe it's just me, but "MAY" seems to invoke "OR MAY NO= T" as a test to see if it was properly applied, and it feels like it fails = here. (That said, "can" isn't much better, but at least it avoids jabber a= bout RFC2119 language.) > > details not present in the first body part that may be useful to >=20 > may -> might Fixed. > > Return of content may be wasteful of network bandwidth and a variety >=20 > may -> can Fixed. > > 4. The text/rfc822-headers Media Type > ... > > to make them legal 7-bit content, they may be encoded with quoted- >=20 > may -> MAY Fixed. > > 6. Security Considerations > ... > > reports may cause the sender to incorrectly believe a message was >=20 > may -> can Fixed. Thanks for the review! -MSK Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0111021F8B36 for ; Thu, 8 Sep 2011 06:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1guboKuc-wph for ; Thu, 8 Sep 2011 06:03:41 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5169C21F8AF4 for ; Thu, 8 Sep 2011 06:03:41 -0700 (PDT) Received: from [192.168.1.7] (adsl-68-122-32-32.dsl.pltn13.pacbell.net [68.122.32.32]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p88D5RDx011450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2011 06:05:33 -0700 Message-ID: <4E68BD97.8050601@dcrocker.net> Date: Thu, 08 Sep 2011 06:05:27 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Murray Kucherawy Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 08 Sep 2011 06:05:33 -0700 (PDT) Cc: Apps Review Subject: [apps-review] Review of -- draft-ietf-appsawg-rfc3462bis-00 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 13:03:42 -0000 I've been asked to do an appsarea review of this draft. Review: Title: The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages draft-ietf-appsawg-rfc3462bis-00 Reviewer: D. Crocker Review Date: 8 Sept 11 Summary: Multipart/Report is an established format for sending reports. It is defined as a MIME media type, motivated by the need to have a standardized format for sending email handling reports. (After the end of an SMTP transfer session, the receiving server still might need to report back to the author or originator. It must send this in an independent email. This media type provides a standardized means of packaging and identifying such reports.) The draft promises a set of minor, non-normative document cleanup changes, and one significant normative change, that of removing a restriction on use of the media type. This change permits the media type to be nested within a MIME structure, rather than being limited to the top level. The restriction was motivated by the original, primary usage scenario for email reporting, but has proved problematic for other scenarios, including something as simple as forwarding a received report(!) Major Issues: None. In pedagogical terms, the need for this change demonstrates the important difference between documenting a usage restriction that applies only to a particular scenario, versus imposing an inherent restriction to the underlying data type. Confusing the two limits utility of the data type. (Formally, the confusion here was between the "packaging" of the data type and the scenario usage of the data type.) Minor Issues: Appendix A (Document History) needs a note to the RFC Editor to remove the section before publishing. Nits: The document repairs non-normative usage of normative vocabulary, to eliminate confusion. It also changes normative vocabulary to be upper case, to aid detection. However it appears that some of these changes were missed: > 3. The multipart/report Media Type ... > generated, for a human reader who may not have a user agent may -> might > report. The text in the first section may be in any MIME may -> MAY {{ I believe. /d }} > details not present in the first body part that may be useful to may -> might > Return of content may be wasteful of network bandwidth and a variety may -> can > 4. The text/rfc822-headers Media Type ... > to make them legal 7-bit content, they may be encoded with quoted- may -> MAY > 6. Security Considerations ... > reports may cause the sender to incorrectly believe a message was may -> can d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Return-Path: X-Original-To: apps-review@ietfa.amsl.com Delivered-To: apps-review@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9F021F8BAC for ; Wed, 7 Sep 2011 15:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, OBSCURED_EMAIL=0.001, RCVD_IN_DNSWL_MED=-4, 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 r0NenvF-KSEi for ; Wed, 7 Sep 2011 15:23:48 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7163621F8E16 for ; Wed, 7 Sep 2011 15:23:43 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p87MPV2V018419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 17:25:31 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p87MPUPX028356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Sep 2011 17:25:31 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p87MPUae009796; Wed, 7 Sep 2011 17:25:30 -0500 (CDT) Message-ID: <4E67EFE5.3030109@bell-labs.com> Date: Wed, 07 Sep 2011 17:27:49 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110817 Fedora/3.1.12-1.fc14 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: draft-ietf-p2psip-base@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: APPS-REVIEW@ietf.org Subject: [apps-review] Apps-area review of draft-ietf-p2psip-base-18 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Apps Area Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 22:23:49 -0000 I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-p2psip-base-18 Title: REsource LOcation And Discovery (RELOAD) Base Protocol Reviewer: Vijay K. Gurbani Review Date: Sep-7-2011 IETF Last Call Date: Not known IESG Telechat Date: Sep-8-2011 Summary: This draft is ready for publication as a Proposed Standard. Major Issues: None. Minor Issues: 1. Nits: Few. Minor Issue: - In S3.6.1, you may want a forward reference to a later section where the well-known server URL is used to fetch the configuration document. Nits: - S2, Terminology: Bootstrap node --- s/help Nlocate/help locate/ - S2, Connection Table: At this point, "Attach" message has not been described. Maybe a forward reference to S5.5.1 will help. - S2, Destination List --- s/A list of IDs/A list of Node-IDs/ - S9, bullet item towards the end of Page 104 --- s/(>1000)/(>1000 peers)/ - S9.5, right before S9.6 starts --- s/(n+2^(128-i)/(n+2^(128-i))/ Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/