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. > > > > 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 ..." > > [...]