Re: [Gen-art] Gen-ART Telechat Review of draft-bryan-metalinkhttp-22

[Anthony Bryan <[e-mail]>]

On Tue, Mar 15, 2011 at 3:46 PM, Ben Campbell <[e-mail]> wrote:
> 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 wait for direction from your document shepherd
> or AD before posting a new version of the draft.
>
> Document: draft-bryan-metalinkhttp-22
> Reviewer: Ben Campbell
> Review Date: 2011-03-15
> IESG Telechat date: 2011-03-17
>
> Summary: This draft is essentially ready for publication as a proposed standard. I have a couple of remaining minor comments that may be worth considering, but probably should not block the draft's progress
>
> Note: This is a followup from my Telechat review of version 21 (see below), which mostly applies to version 22 except for on editorial fix, which I have ellided.
>
> On Mar 1, 2011, at 4:11 PM, Ben Campbell wrote:
>
>> 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 wait for direction from your document shepherd
>> or AD before posting a new version of the draft.
>>
>> Document: draft-bryan-metalinkhttp-21
>> Reviewer: Ben Campbell
>> Review Date:  2011-03-01
>> IETF LC End Date:
>> IESG Telechat date: 2011-03-03
>>
>> Summary: This draft is essentially ready for publication as a proposed standard. I have a couple of remaining comments that may be worth considering, but probably should not block the draft's progress.
>>
>> Major issues:
>>
>> None.
>>
>> Minor issues:
>>
>> -- I note that the draft still suggests that servers SHOULD share an eTag generation policy, but does not offer a baseline policy that servers either SHOULD or MUST implement. I still have a mild concern that implementations might have non-intersecting sets of policy options. On the other hand, I realize that coming up with (i.e. agreeing to) a baseline policy is not a trivial effort in itself, so I don't think this should block publication. I mention it merely for the sake of completeness.

thanks for mentioning it.

>>
>> Nits/editorial comments:
>>
>> -- section 2, last paragraph "Metalink clients use the mirrors provided by a Metalink server in Link header fields [ RFC5988 ] but it is restricted to the initial Metalink server they contacted. "
>>
>> s /"... it is restricted..." / "... this is restricted ..."
>>

fixed.

thanks, Ben!

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