Re: [apps-discuss] apps-team review of draft-bryan-metalinkhttp-19 (fwd)

Anthony Bryan <anthonybryan@gmail.com> Sat, 29 January 2011 23:43 UTC

Return-Path: <anthonybryan@gmail.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A41FA3A68EA; Sat, 29 Jan 2011 15:43:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.335
X-Spam-Level:
X-Spam-Status: No, score=-3.335 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Jp3SOAlSZW8; Sat, 29 Jan 2011 15:43:38 -0800 (PST)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 3B2F03A68DC; Sat, 29 Jan 2011 15:43:36 -0800 (PST)
Received: by ewy8 with SMTP id 8so2205109ewy.31 for <multiple recipients>; Sat, 29 Jan 2011 15:46:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OfhZqqIL9KBM0Sv5CLQ7lGKwD58pdVaKaghVxgett6M=; b=aQBlGatGtfcX0lKYgyVJ4jHYutUBoptKEFH6oZcAHlmzIdNdusPKiL1YfCclcIh8Nm 9skZ9sK62/5GAN4ts+3MdCQU0HDHd05eZiBRARJrmknLijIdh7uFLvLGW8oZyxG+VvnF bl5plyJP1Eqx7AjkeSR09kK5wI/E2AMqYMqms=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OlNzvWYos2+l0afg2RT3f2MQqSns5t03WCUwFGozwkrHC2ZvTg7EZP8T/qwx7oKwiR j1//PnVHlFl9bzTU+JIQ3TfSc5L8PHsQL+pHrGU1cbDuDKUTtki29QRuuoGk3YsxDJEU loWQWKR7l1qCW4gYdi3UytD2l7r9bgWjKReT4=
MIME-Version: 1.0
Received: by 10.213.29.77 with SMTP id p13mr6769708ebc.2.1296344806412; Sat, 29 Jan 2011 15:46:46 -0800 (PST)
Received: by 10.213.98.69 with HTTP; Sat, 29 Jan 2011 15:46:46 -0800 (PST)
In-Reply-To: <alpine.DEB.1.10.1101281158200.25983@wnl.j3.bet>
References: <alpine.DEB.1.10.1101281158200.25983@wnl.j3.bet>
Date: Sat, 29 Jan 2011 18:46:46 -0500
Message-ID: <AANLkTikmGG_O3Z7B0XvKCYiDdioJOc=LDD0+uMPGP3Gf@mail.gmail.com>
From: Anthony Bryan <anthonybryan@gmail.com>
To: Yves Lafon <ylafon@w3.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sun, 30 Jan 2011 08:12:03 -0800
Cc: apps-discuss@ietf.org, apps-review@ietf.org, neil@nabber.org, henrik@henriknordstrom.net, "Ford, Alan" <alan.ford@roke.co.uk>, iesg@ietf.org
Subject: Re: [apps-discuss] apps-team review of draft-bryan-metalinkhttp-19 (fwd)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Jan 2011 23:43:39 -0000

thank you for the review.

On Fri, Jan 28, 2011 at 11:59 AM, Yves Lafon <ylafon@w3.org> wrote:
> (Forwarding to apps-discuss & IESG per request)
>
> --
> Baroula que barouleras, au tiéu toujou t'entourneras.
>
>        ~~Yves
>
> ---------- Forwarded message ----------
> Date: Fri, 28 Jan 2011 10:39:59 -0500 (EST)
> From: Yves Lafon <ylafon@w3.org>
> To: apps-review@ietf.org
> Cc: Alexey Melnikov <alexey.melnikov@isode.com>, anthonybryan@gmail.com,
>    neil@nabber.org, henrik@henriknordstrom.net, tatsuhiro.t@gmail.com,
>    peter@poeml.de, alan.ford@roke.co.uk
> Subject: apps-team review of draft-bryan-metalinkhttp-19
>
> Dear authors,
>
> 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-bryan-metalinkhttp-19
> Title: Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP Header Fields
> Reviewer: Yves Lafon
> Review Date: 2011-01-28
> IETF Last Call Date: 2011-02-18
>
> Summary: This draft is almost ready for publication, but has a few small
> editorial fixes, and possibly needs some minor clarifications.
>
> Major Issues: None
>
> Minor Issues:
>
> In section 3,
>
> Remove
> [[Some organizations have many mirrors.  Only send a few mirrors, or
>  only use the Link header fields if Want-Digest is used?]]
> and add something along the lines of "As some organizations can have many
> mirrors, ..." in front of the next paragraph.

removed.

> Also "network proximity" might be a decision choice for the set of mirrors
> that might be returned.

added.

> In section 3.2
> Did you consider exposing the ASN of the mirror network prefix would be a
> good option on top of Geographical Location? It is not uncommon to have
> better bandwidth between two countries than between two ISPs in the same
> country.

no, this can be done internally on the server side though for mirror
priority (currently via MirrorBrain w/ mod_asn).

Should we mention this in the Mirror Priority section and add a
reference to RFC 1930?

http://www.mirrorbrain.org/
http://www.mirrorbrain.org/mod_asn/

> In section 6.
> <<
> If Instance Digests are not provided by the Metalink servers, the Link
> header fields MUST be ignored.
>>>
> Clarification about what needs ot be ignored:
> "the Link header fields pertaining to this specification MUST be ignored"
> to avoid any zealous reading of the text.

fixed.

> In section 7.
> It might be good that if any Ranged requests generated after the first
> request ends up with a complete response and not a partial one (as servers
> might not support HTTP ranges) then all but the fastest connection must be
> closed. The other option would be to add a requirement in 2. that Metalink
> servers and mirrors MUST support HTTP Ranges (which would be a better way of
> solving the issue).

I added
"If any Ranged requests generated after the first request ends up with
a complete response and not a partial one (as servers might not
support HTTP ranges), then all but the fastest connection can be
closed. "

an earlier draft mentioned that mirrors MUST support HTTP Ranges, but
feedback was that this might exclude mirrors. currently it says
"Mirror servers SHOULD support serving partial content."

we have walked a fine line with not requiring too much on a mirror
network so it's less restrictive and more mirrors can join in the
mirror pool versus having all the features we want.

> Also I noted a dependency on 'draft-ietf-ftpext2-hash' in the Normative
> References section.

yes, we will remove this unless we want draft-ietf-ftpext2-hash to
hold up this document. most likely we will remove it.

> Nits:
>
> In section 3. last paragraph and 7.1.1 6th paragraph, "fieldss" -> "fields"
> In section 6. "Cryptographic Hashes of Whole Files",
>              "Files" might be replaced by "Documents"

changed to "Documents". or would "Resources" be better?

thanks!
-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads