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-bryan-metalinkhttp-19 Reviewer: Ben Campbell Review Date: 2011-02-11 IETF LC End Date: 2011-02-11 Summary: This document is on the right track for a proposed standard, but there are open issues and editorial issues that should be addressed prior to publication. --- Major issues: none. --- Minor issues: -- Section 1, paragraph 1, first sentence: Is this really intended as an alternative to Metalink/XML? It seems like more of a complementary approach than an alternative one. -- section 2, third paragraph: If they must have the same eTag policy, should this document not specify at least one mandatory-to-implement policy? -- section 2, last paragraph: "Metalink clients MAY make use of digital signatures if they are offered." That seems too weak. We usually recommend that people check signatures on downloads when available. Wouldn't we want an automated system to treat this as at least a SHOULD? -- section 3, 4th paragraph: "[[Some organizations have many mirrors. Only send a few mirrors, or only use the Link header fields if Want-Digest is used?]]" Open issue? -- section 3.3, 1st paragraph:"([draft-ietf-ftpext2-hash] allows for FTP mirrors to be coordinated and provide file hashes)." Do you mean to allow such FTP servers to be preferred? -- section 4.1 "This is particularly useful for providing metadata such as cryptographic hashes of parts of a file, allowing a client to recover from partial errors (see Section 7.1.2)." Seems like this might warrant a SHOULD. -- section 5, last paragraph: "Metalink clients MAY support the use of OpenPGP signatures." MAY seems weak here. This means that the publisher of a file has no reasonable expectation that clients will check the signature. -- section 6, 3rd paragraph: "Digest: SHA-256=..." Example needs more context -- section 7, 4th paragraph from end: "Downloads from mirrors that do not have the same file size as the Metalink server are considered unusable and the client can deal with it as it sees fit." What if the client sees fit to use it? Is there a normative "client SHOULD NOT" implied here? -- section 7.1.1, 1st paragraph:"the requirement is that merging of ranges from multiple responses must be verified" The requirement for what? Is this intended to be normative? -- section 7.1.2, 2nd paragraph:"If no partial cryptographic hashes are available, then the client MUST fetch the complete object from other mirrors." Does this imply that the client also MUST fetch from other mirrors if the hashed are present but fail verification? -- section 8, last paragraph: "The size of chunks chosen by the client should be sufficiently large that the chunk request header fields and reponse header fields represent neglible overhead, and sufficiently large that they can be pipelined effectively without needing a very high rate of chunk requests." Can you provide guidance on what "sufficiently large", and "negligible overhead" mean, either in terms of examples or real numbers? "Note that Range requests impose an overhead on servers and clients need to be aware of that and not abuse them." What constitutes abuse? Can you provide more specific guidance on when range should not be used, since all the other guidance seems to suggest using it? -- section 10.2: What can an implementor do to mitigate spoofing? -- section 10.4: This section should include a warning that clients only have a MAY level requirement to support signature verification. "Metalinks should include digital signatures, as described in Section 5." Normative? -- section 11.1, [BITTORRENT] Is bittorrent.org an acceptable SDO for the purposes of normative references? (I'm not saying it's not--just asking) [draft-ietf-ftpext2-hash] -- is this a normative downref? --- Nits/editorial comments: -- section 2, 4th paragraph: "HTTP mirror servers SHOULD share the same ETag policy as the originating Metalink server." -- section 2, 5th paragraph: "Metalink clients use the mirrors provided by a Metalink server with Link header fields [RFC5988]." Sentence seems ambiguous. Do you mean "_in_ Link header fields." -- section 3, 2nd paragraph: "A brief Metalink server response with two mirrors only:" Sentence fragment -- section 3, last paragraph: "fieldss" Typo. (Note same typo repeats throughout) "Such a decision could be a hard-coded limit, a random selection, based on file size, or based on server load." I assume this is not meant to be exhaustive? -- section 3.3, last paragraph: Paragraph is redundant with similar normative statements in section 2 -- section 4.1: "as shown in Section 4." .. as shown in the example in section 4. -- section 6, 1st paragraph: "Metalink servers MUST provide Instance Digests in HTTP [RFC3230] for files they describe with mirrors via Link header fields." Redundant with previously mentioned normative requirement. -- section 7, paragraph starting with: "If no range limit was given in the original request then work from the tail of the object (the first request is still running and will eventually catch up), otherwise continue after the range requested in the first request." Implied "you". Restate as "the client works from the tail" (Please avoid use of 2nd person pronouns in an RFC, implied or otherwise) (Note that this usage is sprinkled throughout ) "If no Range was provided," ... in the original request,... Also, be careful with the passive voice in this paragraph. Who undertakes HEAD requests first? Who undertakes Range-based requests? -- section 7, paragraph 10: "If-Match conditions based on the ETag SHOULD be used..." Clients should use If-Match conditions... "If no indication of ETag syncronisation/ knowledge is given then If-Match should not be used, and optimally there will be an Instance Digest in the mirror response which we can use to detect a mismatch early, and if not then a mismatch won’t be detected until the completed object is verified." Is there any way other than the pref parameter to indicate this? If not, it would be better to say "if no pref parameter is present..." Is this sentence intended to be normative? Also, "... The client should not use..." Finally, the sentence is hard to follow--please break it up. -- section 7.1.1, general: This whole section switches to an almost stream-of-consciousness style. It has very long sentences with many comma separated clauses that are hard to follow. It really needs to be rewritten to be more readable and precise. -- section 7.1.1, paragraph 3: Paragraph seems self contradictory. How is guaranteeing correct content different than verifying integrity? -- paragraph 4: "This guarantees that a mismatch will be detected by using only the synchronized ETag from a master server and mirror server, even alerted by the mirror servers themselves by responding with an error, preventing accidental merges of ranges from different versions of files with the same name." I can't parse this sentence. "This even includes many malicious attacks where the data on the mirror has been replaced by some other file, but not all." Antecedent of "this" is ambiguous -- 2nd to last paragraph: This is the first mention of e idea of slave and master mirror servers. Is this the same as preferred and normal mirrors? Please use consistent terms. -- section 7.1.2, 2nd paragraph: "If the object cryptographic hash does not match the Instance Digest then fetch the Metalink/XML if available, where partial file cryptographic hashes can be found, allowing detection of which server returned incorrect data." I can't parse this sentence. -- section 8, paragraph after bullet list: Please avoid first person pronouns in an RFC. "Based on laboratory experiments,..." Reference? "we suggest a good default number of simultaneous connections is probably four," That's very weak language--can you remove "we suggest" and "probably"? -- Section 9, 1st paragraph: "registration to the Link Relation Type registry" Can you provide the URL to the registry? -- section 10.2 "In that case, this could deceive unaware downloaders that they are downloading a malicious or worthless file." Sentence does not make sense. Does the attacker with to deceive them into downloading a malicious file, or convince them that they are when they are not? _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf