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

Anthony Bryan <> Sat, 29 January 2011 23:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A41FA3A68EA; Sat, 29 Jan 2011 15:43:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.335
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1Jp3SOAlSZW8; Sat, 29 Jan 2011 15:43:38 -0800 (PST)
Received: from ( []) by (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;; 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;; 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 with SMTP id p13mr6769708ebc.2.1296344806412; Sat, 29 Jan 2011 15:46:46 -0800 (PST)
Received: by with HTTP; Sat, 29 Jan 2011 15:46:46 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Sat, 29 Jan 2011 18:46:46 -0500
Message-ID: <>
From: Anthony Bryan <>
To: Yves Lafon <>
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:,,,, "Ford, Alan" <>,
Subject: Re: [apps-discuss] apps-team review of draft-bryan-metalinkhttp-19 (fwd)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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 <>
> To:
> Cc: Alexey Melnikov <>,,
> 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
> 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.


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


> 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?

> 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.


> 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?

(( Anthony Bryan ... Metalink [ ]
  )) Easier, More Reliable, Self Healing Downloads