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

From: Yves Lafon <[email-masked]>
Date: Fri, 28 Jan 2011 11:59:03 -0500 (EST)

(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 <[email-masked]>
To: [email-masked]
Cc: Alexey Melnikov <[email-masked]>, [email-masked],
     [email-masked], [email-masked], [email-masked],
     [email-masked], [email-masked]
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.

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.

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

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

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"

Thanks !

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: Anthony Bryan <[email-masked]>
Date: Sat, 29 Jan 2011 18:46:46 -0500

thank you for the review.

> (Forwarding to apps-discuss & IESG per request)

removed.

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

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

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

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

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