Re: [apps-review] Suggested changes for Applications Area Review Team

[SM <[e-mail]>]

Hi John,
At 09:33 19-03-2011, John C Klensin wrote:
>This generally looks ok.   I agree with Dave -- implicit ACK is
>not a good protocol, especially so when you are anticipating a
>24 hour timeout.  As strange as the idea may seem, some of us do
>end up with travel, day job, or other commitments that might
>result in our being offline wrt review team messages for
>significantly longer than that (e.g., while I hope to do better,
>my current expectation is that I'll be offline all of the week
>starting April 4 due to circumstances entirely beyond my
>control).

For what it is worth, some of the reminders I send go 
unanswered.  The people who have been arguing against implicit ACK 
are the same people who reply within 24 hours and who perform the 
assignments. :-)  I mentioned it in my previous replies and I'll say 
it to you too, I agree with the arguments you raised above.

If you look at the tracker ( 
http://www.apps.ietf.org/content/apps-review-tracker ), you will see 
that there was only one review in July 2010.  The month after that 
was an odd case.  There were 14 reviews in September, 2010.  This was 
preceded by discussions on how to make the team functional.  The drop 
in January 2011 is due to the end of year season.  February and March 
were slow as I received a few review requests.

>Although I usually try to make "major/minor/nits" distinctions
>when doing reviews, I agree with Dave that it can sometimes be
>very difficult,  with rather subjective boundaries, and
>time-consuming.  I think you should try to be clear about
>priority for that sort of breakdown when you might be able to
>get it only at the price of a delayed review or no review at
>all.

The major/minor/nits distinction is what typically appears in our 
reviews.  It is not an ID-nits that the review must pass.  I 
personally would not ask for a specific format for reviews.  The Apps 
Area ADs may have a preference.  I'll defer to them on that as our 
task is also to make their work easier.

There is an indirect readership.  Some people not be familiar with 
the IETF might be considering writing an I-D.  It is easier for them 
to learn from the reviews about what major issues to look out for if 
there are these boundaries.  It takes time for people to understand 
that the boundaries are subjective.  There is nothing this team can 
do about that.

I'll leave it to Alexey, Peter and Pete to comment on the priority 
for the breakdown.

>Perhaps as the basis for a different classification system for
>standards track documents, I also think that it would be very
>useful to get a reviewer opinion that distinguished between "not
>yet ready for publication given the criteria for the relevant
>maturity level in RFC 2026 (as amended)" and "not ready for
>publication using other criteria that the author thinks are
>appropriate".  Especially from the standpoint of those of us who
>believe that the IETF spends too much time fine-tuning
>early-stage specifications, making that distinction might be
>helpful for the IESG and a useful reminder for everyone else.

This is again subjective as we may have different views about RFC 
2026.  From an Apps Area perspective, I do not feel strongly about 
this.  I may have different views if you ask me on another mailing list. :-)

There is always room for improvement in an I-D.  An I-D with an 
intended status of Proposed Standard might have a higher bar than one 
intended as Experimental.  If a document is not ready for publication 
as Proposed Standard, it does not mean that the document does not fit 
the criteria for Experimental.  A review could recommend a different 
publication status.

>Finally, I strongly favor your inclination (and Martin's) to
>make this process descriptive rather than normative/rigid.

Although I did not mention it on this thread, I am aware that 
everyone on the team is doing volunteer work.  Some of you may be 
doing the reviews during your free time and you have other 
commitments as well.  Although I could ask for team members to be 
dropped from the team, it is the Apps Area ADs that have the final 
say.  I can only say "please do the assignment".

Best regards,
-sm