Re: [Gen-art] Gen-ART LC Review of draft-bryan-metalinkhttp-19

[Anthony Bryan <[e-mail]>]

On Wed, Feb 16, 2011 at 6:15 PM, Ben Campbell <[e-mail]> wrote:
> Thanks for the quick response. I haven't had a chance to look at the new version yet, but here are my responses to your email comments. I removed sections where I had no further (non-trivial) comment. Please consider any removed parts to be the same as an "Okay" response.
>
> Thanks!
>
> Ben.
>
> On Feb 14, 2011, at 4:43 PM, Anthony Bryan wrote:
>
> [...]
>
>> was there supposed to be a comment along with
>>
>> -- section 2, 4th paragraph: "HTTP mirror servers SHOULD share the
>> same ETag policy as the originating Metalink server."
>> ?
>
> I responded to this one below.
>
>>
>> On Fri, Feb 11, 2011 at 6:46 PM, Ben Campbell <[e-mail]> wrote:
>
> [...]
>
>>>
>>> -- 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.
>>
>> well...you could use either, or both :)
>>
>> "Metalink/HTTP is an alternative and complementary representation of
>> Metalink information,"...
>> ?
>
> WFM
>
>>
>>> -- section 2, third paragraph:
>>>
>>> If they must have the same eTag policy, should this document not specify at least one mandatory-to-implement policy?
>>
>> SHOULD share the same ETag policy.
>>
>> I added:
>>
>> "It is up to the administrator of the Metalink server to communicate
>> the details of the shared ETag policy to the administrators of the
>> mirror servers so that the mirror servers can be configured with the
>> same ETag policy."
>
> My comment was about policy implementation, not policy configuration.
>
> Do you expect the method to generate ETags to be configurable in most implementations? Is that the case among common HTTP servers today? (That's not rhetorical--I don't know the answer.) And even if it is, is there a risk that there won't be a common selection between implementations? It doesn't help to tell an administrator to select a certain policy unless his software can actually do it. If there was a mandatory-to-implement policy, then that shouldn't happen.

Apache has an option that fits. I don't know about other server
software. obviously, this would need to be added for them to be able
to be Metalink servers if they don't have it. but, at least initially,
I don't expect every web server to easily be able to also be a
Metalink server without changes.

>
> [...]
>
>>
>>> -- section 10.2:
>>>
>>> What can an implementor do to mitigate spoofing?
>>
>> nothing, I'm aware of?
>>
>> added:
>> As with all downloads, users should only download from trusted sources.
>
> Hmm. What does "trusted" mean in context? Does that have implications on authentication of the source and integrity protection of the download session? (i.e. TLS)?

I'm not sure how to word this. a non-TLS source like download.com
could be more trusted than a TLS one from denialofserviceRus.com

> [...]
>
>>> --- Nits/editorial comments:
>>>
>>> -- section 2, 4th paragraph: "HTTP mirror servers SHOULD share the same ETag policy as the originating Metalink server."
>>
>> what's wrong here?
>
> Oops, sorry, cut-and-paste error. My comment was "This seems redundant with a similar statement in the previous paragraph"

there is a paragraph on the Metalink server, mirror server, and
client. I think it's ok to reiterate.

paragraph 3 on Metalink servers:
Metalink servers and their associated mirror servers SHOULD all share
the same ETag policy.

paragraph 4 on Mirror servers:
HTTP mirror servers SHOULD share the same ETag policy as the
originating Metalink server.

>
> [...]
>
>
>>> -- 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.
>>
>> hahaha :)
>>
>> this is my fault as a bad editor & a non-native English speaker co-author.
>>
>
> On reflection, I think my comment was a little harsh. But another pass with some attention to style in the section would help.

no, it needed work.

here's our next pass
http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-bryan-metalinkhttp-20.txt&url2=http://www.metalinker.org/test/mh/draft-bryan-metalinkhttp-21.txt

>>> -- section 7.1.1, paragraph 3:
>>>
>>> Paragraph seems self contradictory. How is guaranteeing correct content different than verifying integrity?
>>
>> the server sends the correct content  but there can be errors during transfer.
>>
>> maybe this is not explicit enough. might need to condense some of this down.
>
>> earlier we state:
>> Error detection requires Instance Digests to detect errors in transfer
>> after the transfers have completed.
>>
>
> I think a rewording would help, as I took "guaranteeing correct content" to mean "guaranteeing the client receives correct content" rather than "guaranteeing the server sends correct content".

"ETags can not be used for verifying the integrity of the received
content. If the ETag given by the mirror server matches the ETag given
by the Metalink server, then the Metalink client assumes the responses
are valid for that object. "


>>> -- 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.
>>
>>   If the cryptographic hash of the object does not match the Instance
>>   Digest from the Metalink server, then the client SHOULD fetch the
>>   Metalink/XML (if available) that could contain partial file
>>   cryptographic hashes which will allow detection of which mirror
>>   server returned incorrect data.  Metalink clients SHOULD figure out
>>   what ranges of the downloaded data can be recovered and what needs to
>>   be fetched again.
>
> That's better, but how about breaking it up a bit more, as in the following:
>
> "  If the cryptographic hash of the object does not match the Instance Digest from the Metalink server, then the client SHOULD fetch the Metalink/XML (if available). This may contain partial file cryptographic hashes which will allow detection of which mirror server returned incorrect data.  Metalink clients SHOULD use the Metalink/XML data to figure out what ranges of the downloaded data can be recovered and what needs to be fetched again. "
>

perfect, thanks!




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