[Gen-art] Gen-art last call review : draft-ietf-geopriv-deref-protocol-03

Elwyn Davies <elwynd@dial.pipex.com> Sun, 23 October 2011 17:19 UTC

Return-Path: <elwynd@dial.pipex.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F076221F8B05 for <gen-art@ietfa.amsl.com>; Sun, 23 Oct 2011 10:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.555
X-Spam-Level:
X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 5b9HWI24FuRE for <gen-art@ietfa.amsl.com>; Sun, 23 Oct 2011 10:19:16 -0700 (PDT)
Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by ietfa.amsl.com (Postfix) with ESMTP id 430B221F8AF7 for <gen-art@ietf.org>; Sun, 23 Oct 2011 10:19:15 -0700 (PDT)
X-Trace: 492365525/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-INTERNET-ACCEPTED/None/212.183.132.20/None/elwynd@dial.pipex.com
X-SBRS: None
X-RemoteIP: 212.183.132.20
X-IP-MAIL-FROM: elwynd@dial.pipex.com
X-SMTP-AUTH: elwynd@dial.pipex.com
X-Originating-Country: GB/UNITED KINGDOM
X-MUA: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuQBAGlLpE7Ut4QU/2dsb2JhbAAMLgkmrB4vETANFhgDAgECAUsBDAgBAYgEtQyFEoMuBJQJhRmMQw
X-IronPort-AV: E=Sophos;i="4.69,394,1315177200"; d="scan'208";a="492365525"
X-IP-Direction: OUT
Received: from host212-183-132-20.uk.access.vodafone.net (HELO [10.139.195.242]) ([212.183.132.20]) by smtp.pipex.tiscali.co.uk with ESMTP; 23 Oct 2011 18:19:05 +0100
Message-ID: <4EA420A6.4090702@dial.pipex.com>
Date: Sun, 23 Oct 2011 15:11:50 +0100
From: Elwyn Davies <elwynd@dial.pipex.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: General Area Review Team <gen-art@ietf.org>, draft-ietf-geopriv-deref-protocol.all@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [Gen-art] Gen-art last call review : draft-ietf-geopriv-deref-protocol-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Oct 2011 17:19:36 -0000

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments 
you may receive.

Document: draft-ietf-geopriv-deref-protocol-03.txt
Reviewer: Elwyn Davies
Review Date: 23 October 2011
IETF LC End Date: 25 October 2011
IESG Telechat date: (if known)  -

Summary:

Major issues:

Minor issues:
Appendix A: Compliance statement for Req 4:  The Compliance statement 
states that use of HTTPS from Location Recipient to LS is mandated.  I 
cannot find any MUST statement to this effect in the main body of the 
document.  There is a statement in s1 that sort of implies this but 
there is no statement with RFC 2119 language in it to make this 
mandatory in the body of the specification. Further, I am slightly 
confused by the ability to use http scheme URLs, which I assume would 
allow (indeed expect) unsecured HTTP to be used.

Appendix A: Compliance statement for Req 4:  Use of the HTTP over TLS 
PKI infrastructure, would I suppose be implicit if the previous comment 
were fixed.  However, it might be good to make this explicit.

Appendix A: Compliance statement for Req 9:  Again, the body of the 
specification is silent on what a Location Reciepient may or may not do 
with a Location URL.  Clearly any constraints are not enforceable within 
the context of the HELD protocol but it is probably desirable to note 
the policy of non-propagation implied by Req 9.

Appendix B: Compliance statement for Req C3: Compliance for Auth by 
Possession seems somewhat dubious.  Derogation due to the requirement 
for expiry is discussed in the body of the document.

Appendix B: Compliance statement for Req C8: The explicit requirement 
for a minimum of 128 bits of randomness does not appear in the body of 
the document.  Since the requirements doc is informational, this needs 
to be made explicit in the main body of the doc.

Appendix C: Compliance statement for Req D5:  See comments above on App 
A, Req 4.  May be a contradiction here: App A appears to require a MUST; 
this compliance implies a RECOMMENDS and possibility of http.  Needs 
sorting out.

Nits/editorial comments:

Abstract: Acronym HELD needs to be expanded here (currently expanded in s1).

s1, Figure 1: (PIcky nit): The infomation carried by the two xxxRequest 
messages is technically a request for xxx rather than the actual object.

s3.2, para 2: s/before before/before/

s5, Figure 5: (Picky nit): The indentation is slightly inconsistent 
<geopriv> element  only indented one space.

Appendix A, Req 12 bullet (b): s/about the identity about the 
Target/about the identity of the  Target/