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

[Anthony Bryan <[e-mail]>]

thank you for the review.

On Fri, Jan 28, 2011 at 11:59 AM, Yves Lafon <[e-mail]> 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 <[e-mail]>
> To: [e-mail]
> Cc: Alexey Melnikov <[e-mail]>, [e-mail],
>    [e-mail], [e-mail], [e-mail],
>    [e-mail], [e-mail]
> 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