Subject: Re: [apps-review] [apps-discuss] apps-team review of draft-bryan-metalinkhttp-19 (fwd)
From: Anthony Bryan <[email-masked]>
To: Yves Lafon <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], "Ford, Alan" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Date: Sat, 29 Jan 2011 18:46:46 -0500
List-Id: Apps Area Review List <apps-review.ietf.org>

thank you for the review.

On Fri, Jan 28, 2011 at 11:59 AM, Yves Lafon <[email-masked]> wrote:
> (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.

removed.

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

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

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

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

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

changed to "Documents". or would "Resources" be better?

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

Date: Sat, 29 Jan 2011 00:59:57 +0300
From: Alexey Melnikov <[email-masked]>
To: [email-masked]
Subject: [apps-review] The importance of Apps Review team reviews

Hi,
[Slowly replying to messages in this thread while on holidays.]

SM wrote:

> I think that the Apps Area Directors find the reviews useful or else 
> they would not have asked for it.

Indeed, I can confirm that Peter and I read reviews and take them into 
consideration. Maybe we should explicitly acknowledge that we do, 
especially in situations when editors of documents also read reviews but 
don't reply to them.

I can also say that as an AD, I am really grateful to these reviews, as 
I believe they improve quality of documents that Apps ADs need to 
sponsor or review.

Thank you,
Alexey

-- 
IETF Application Area Director, <http://www.ietf.org/iesg/members.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address

Date: Fri, 28 Jan 2011 11:57:51 -0500 (EST)
From: Yves Lafon <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] apps-team review of draft-bryan-metalinkhttp-19

On Fri, 28 Jan 2011, SM wrote:

> Hi Yves,
> At 07:39 28-01-11, Yves Lafon wrote:
>> Document: draft-bryan-metalinkhttp-19
>> Title: Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP Header 
>> Fields
>> Reviewer: Yves Lafon
>> Review Date: 2011-01-28
>
> Thanks for the doing the review.  Could you please also sent your review to 
> [email-masked] and [email-masked]?

Sure.

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

         ~~Yves

Date: Fri, 28 Jan 2011 08:21:05 -0800
To: Yves Lafon <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] apps-team review of  draft-bryan-metalinkhttp-19

Hi Yves,
At 07:39 28-01-11, Yves Lafon wrote:
>Document: draft-bryan-metalinkhttp-19
>Title: Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP Header Fields
>Reviewer: Yves Lafon
>Review Date: 2011-01-28

Thanks for the doing the review.  Could you please also sent your 
review to [email-masked] and [email-masked]?

Best regards,
-sm

Date: Fri, 28 Jan 2011 10:39:59 -0500 (EST)
From: Yves Lafon <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [apps-review] 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: Mark Nottingham <[email-masked]>
To: SM <[email-masked]>
Date: Thu, 27 Jan 2011 17:03:35 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: John C Klensin <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [apps-review] Feeling kind of confused about	draft-merrick-jms-uri-12

On 28/01/2011, at 7:13 AM, SM wrote:

>>  But the IETF is
>> periodically accused of having procedures that work only for
>> those who know how to use them and I periodically feel an
>> obligation to explain possibly-useful procedures to those whose
>> only other recourse would be whining and/or ranting.

Perhaps we need a document like the TAO, but more detailed/advanced; sort of a TAO Stage II.

--
Mark Nottingham       [email-masked]

Date: Thu, 27 Jan 2011 12:13:31 -0800
To: John C Klensin <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Feeling kind of confused about draft-merrick-jms-uri-12

Hi John,
At 10:24 27-01-11, John C Klensin wrote:
>Talking with the Apps Area Directors is the first (and normally
>last) step on that path.  The difference is only the level of
>formality.  Remember that the purpose of the IETF Appeals model
>is to get a careful second look at areas of disagreement and to
>attempt to see if agreement can be reached, not to initiate or
>proceed with a judicial function of any sort.

Yes.

>I don't believe that anything improper has occurred in the
>review process or even in the IESG decision.   I appreciate your

Yes.

>I do believe that, if people feel strongly that accepting the
>document and registration was a seriously bad idea, even after
>they are sure they understand the nature of a provisional
>registration, then they should try to understand the IESG's
>reasoning from the Apps ADs and/or ask that the decision be
>reviewed.

My comments are not from a provisional registration angle.  It has 
been quite an effort to jump-start the team and to get the reviewers 
to do the assignments.  There were 36 assignments that have been 
completed and four I-Ds are still pending review.  If I do not help 
the reviewers get more information about the reasoning, there may be 
a feeling that doing the assignments is not worth the time and effort.

Being Team Lead can either be viewed as a career path or about 
helping the team.  I prefer to do the latter.  Based on my short 
experience of working with Alexey and Peter, I can say that they have 
helped a lot in getting the team working and they do take the reviews 
seriously.  Alexey has already replied to Tim's comment off-list.

>It would also be quite reasonable for people who find themselves
>in that position to request additional text -- in a revised
>announcement statement, in the registry, or in the document as
>it will be published -- to suggest that.  Whether that could be
>negotiated with the Apps ADs or required a formal appeal would
>be up to the ADs and the IESG.
>
>I am not personally convinced that either trying to get a
>different decision or trying to get more clear disclaimers or
>warnings into the text would be worthwhile.  But the IETF is
>periodically accused of having procedures that work only for
>those who know how to use them and I periodically feel an
>obligation to explain possibly-useful procedures to those whose
>only other recourse would be whining and/or ranting.

Thanks for explaining the procedures.

Best regards,
-sm 

Date: Thu, 27 Jan 2011 13:24:38 -0500
From: John C Klensin <[email-masked]>
To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Feeling kind of confused about draft-merrick-jms-uri-12

--On Thursday, January 27, 2011 09:44 -0800 SM
<[email-masked]> wrote:

> Hi John,
> 
> [following up on apps-review]
> 
> At 23:20 26-01-11, John C Klensin wrote:
>> Remember too that, as Mark has already pointed out in a
>> different way, the main point of a provisional registration is
>> to lower the odds that the same protocol identifier string
>> will be used to designate two different protocols.
> 
> Mark and you have commented on this case.  There was a comment
> from Larry (
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg0
> 2096.html ).
> 
>> I am not advising this in any way and I personally don't think
>> it would be worth the effort, but, in the interest of
>> procedural knowledge and consistency, RFC 2026 does give
>> anyone who feels strongly about this decision the right to
>> appeal it.
> 
> I suggest talking to the Apps Area Directors before taking
> that path.

Talking with the Apps Area Directors is the first (and normally
last) step on that path.  The difference is only the level of
formality.  Remember that the purpose of the IETF Appeals model
is to get a careful second look at areas of disagreement and to
attempt to see if agreement can be reached, not to initiate or
proceed with a judicial function of any sort.

> When a request for review come from the Apps Area Directors, I
> pick a reviewer for the assignment.  There was a case where
> the document was over 300 pages and there was a short
>...
> It has been difficult to get all the reviews done.  I value
> the contributions made by Tim and all members of the team.  I
> may voice my discontent to the Apps Area ADs if a reviewer
> mentions that his/her work is not given any consideration.

I don't believe that anything improper has occurred in the
review process or even in the IESG decision.   I appreciate your
review of the history.

I do believe that, if people feel strongly that accepting the
document and registration was a seriously bad idea, even after
they are sure they understand the nature of a provisional
registration, then they should try to understand the IESG's
reasoning from the Apps ADs and/or ask that the decision be
reviewed.

It would also be quite reasonable for people who find themselves
in that position to request additional text -- in a revised
announcement statement, in the registry, or in the document as
it will be published -- to suggest that.  Whether that could be
negotiated with the Apps ADs or required a formal appeal would
be up to the ADs and the IESG.

I am not personally convinced that either trying to get a
different decision or trying to get more clear disclaimers or
warnings into the text would be worthwhile.  But the IETF is
periodically accused of having procedures that work only for
those who know how to use them and I periodically feel an
obligation to explain possibly-useful procedures to those whose
only other recourse would be whining and/or ranting.

    john

Date: Thu, 27 Jan 2011 09:44:03 -0800
To: John C Klensin <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: [apps-review] Feeling kind of confused about draft-merrick-jms-uri-12

Hi John,

[following up on apps-review]

At 23:20 26-01-11, John C Klensin wrote:
>Remember too that, as Mark has already pointed out in a
>different way, the main point of a provisional registration is
>to lower the odds that the same protocol identifier string will
>be used to designate two different protocols.

Mark and you have commented on this case.  There was a comment from 
Larry ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02096.html ).

>I am not advising this in any way and I personally don't think
>it would be worth the effort, but, in the interest of procedural
>knowledge and consistency, RFC 2026 does give anyone who feels
>strongly about this decision the right to appeal it.

I suggest talking to the Apps Area Directors before taking that path.

When a request for review come from the Apps Area Directors, I pick a 
reviewer for the assignment.  There was a case where the document was 
over 300 pages and there was a short deadline.  I mentioned to the 
ADs that it would be too much work and they agreed not to request a 
review by the team.  The assignment task generally works like this:

  (a) Receive request for review

  (b) Verify whether the document is relevant to the Apps Area
      and that there is a team member with the expertise to
      perform the review

  (c) Assign the review to a team member

  (d) Add the document to the Apps Area Review tracker

  (e) Send out reminders to the reviewer

  (f) Update the Apps Area Review tracker once the review is submitted

I think that the Apps Area Directors find the reviews useful or else 
they would not have asked for it.  Some authors respond to the 
reviews.  For example:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01740.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01814.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01828.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01835.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02124.html

The Apps Area Team reviews are also copied to the IESG as an AD asked 
for that after he read one of the Apps Area reviews.  The reviews are 
also read by future authors and it can help them when they write an 
Internet-Draft.

It has been difficult to get all the reviews done.  I value the 
contributions made by Tim and all members of the team.  I may voice 
my discontent to the Apps Area ADs if a reviewer mentions that 
his/her work is not given any consideration.

Best regards,
-sm 

Date: Fri, 21 Jan 2011 12:38:19 -0800
To: Yves Lafon <[email-masked]>
From: SM <[email-masked]>
Cc: [email-masked]
Subject: [apps-review] Request for review: draft-bryan-metalinkhttp

Hi Yves,

Alexey requested a review of  draft-bryan-metalinkhttp.  The review 
has been assigned to you and is due before January 28.  You can find 
information about the author and WG in the datatracker ( 
https://datatracker.ietf.org/doc/ draft-bryan-metalinkhttp ).  Some 
previous reviews from the Apps-review Team are accessible at 
http://www.apps.ietf.org/content/apps-review-template

The review should be sent to apps-discuss, the author, WG Chair and 
document shepherd, if applicable, and the IESG.  The subject of the 
email when submitting the review should be "apps-team review 
of  draft-bryan-metalinkhttp-19".

Best regards,
-sm

Date: Sun, 09 Jan 2011 10:24:39 -0800
To: [email-masked]
From: SM <[email-masked]>
Subject: [apps-review] Review of draft-lear-iana-timezone-database-01

Hello,

Ted Hardie submitted a review of draft-lear-iana-timezone-database-01 
to Eliot Lear and the Apps Area ADs on January 6.  Ted requested that 
the review be kept private because it takes into account some issues 
which are related to the IANA Function.

As Eliot and the Apps ADs agreed to the request, the review of 
draft-lear-iana-timezone-database-01 will not be posted.

Best regards,
-sm