wiki:template

Applications Area Directorate Review Template

This page provides a template for reviews provided by members of the Application Area Directorate.

Authors: The information near the bottom of this page is to help you respond to the reviews.

Reviewers: Please send all reviews to the apps-discuss list (not to the appsdir list) and to the ".all" alias for the specification you are reviewing (see below)!

In cases where your review recommends significant changes to a working-group document, you should also consider copying the working group's mailing list.!

You might also want to check out some samples, such as the reviews of draft-merrick-jms-uri, draft-dusseault-http-patch-15, draft-ietf-core-link-format-11 and draft-ietf-decade-arch-04.

As the process for a review which is requested by Application Area Directors during an IETF general Last Call, and the one when the review is requested by a Working Group Chair during a WG last call is different, we suggest using two slightly different templates.

Template for standard review during IETF Last Call

Suggested distribution list for reviews: To: apps-discuss@…, draft-name-without-version-num.all@… cc: iesg@…

Note: The review is only copied to the IESG if a Last Call has been issued.

I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: [document name, such as draft-foo-bar-baz]
Title: [document title]
Reviewer: [your name here]
Review Date: [today's date or the date of your review]
IETF Last Call Date: [include if known]
IESG Telechat Date: [include if known]

Summary: [Provide a one-sentence summary of the review.]

(Examples include "This draft is ready for publication as an Experimental RFC", "This draft is almost ready for publication as an Informational RFC but has a few issues that should be fixed before publication", and "This draft is not ready for publication as a Proposed Standard and should be revised before publication".)

Comments: [provide, if any, any specific general comments on the draft]

[example: In general I believe this draft is not addressing correctly the issue it describes in the title, and needs further thinking before progressing, the reasons are... bla bla bla...]

Major Issues: [list any major issues such as application-related concerns, preferably by section number]

Minor Issues: [list any minor issues such as advice or discussion which is missing from the draft, text that is unclear or confusing, preferably by section number]

Nits: [list editorial issues such as typographical errors, preferably by section number]

Template for early review during a WG Last Call

Suggested distribution list for reviews: To: apps-discuss@…, draft-name-without-version-num.all@… cc: iesg@…

Note: The review is very rarely copied to the IESG unless there is really a need to, but may be copied to the whole WG list if needed.

I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your WG chairman(s) before posting a new version of the draft.

Document: [document name, such as draft-foo-bar-baz]
Title: [document title]
Reviewer: [your name here]
Review Date: [today's date or the date of your review]
WG Last Call Date: [include if known]

Summary: [Provide a one-sentence summary of the review.]

(Examples include "This draft is ready to progress for an IETF Last call before publication as an Experimental RFC", "This draft is almost ready to progress for an IETF Last Call before publication as an Informational RFC but has a few issues that should be fixed before publication", and "This draft is not ready to progress now as a Proposed Standard and should be revised before an IETF Last Call is issued".)

Comments: [provide, if any, any specific general comments on the draft]

[example: In general I believe this draft is not addressing correctly the issue it describes in the title, and needs further thinking before progressing, the reasons are... bla bla bla...]

Major Issues: [list any major issues such as application-related concerns, preferably by section number]

Minor Issues: [list any minor issues such as advice or discussion which is missing from the draft, text that is unclear or confusing, preferably by section number]

Nits: [list editorial issues such as typographical errors, preferably by section number]

Information for document authors

In plain English, this means that the comments in the review does not bear more weight than a comment submitted by an individual during a Last Call.

The Applications Area Directors may or may not agree with the comments of the Applications Area Directorate reviewer. The Applications Area Directorate does not have any veto power on a draft. It is suggested that the author(s) asks the document shepherd (RFC 4858) or the Area Director who sponsored the draft for guidance about IETF process, changes that should be made, whether to post a new revision, etc.

A review generally list issues as major or minor. A review performed by Ted Hardie is used as an example ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04847.html ).

The reviewer explained why he considered some issues as major. The author discussed about the issues with the reviewer ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04859.html ). There isn't a clear-cut rule on what is a major or minor issue. It's up to the reviewer to make a judgement call. It is up to the author(s), or working group, to decide about whether these issues should be resolved and how to do so.

Some Applications Area Directorate reviews may list nits. These nits are generally editorial issues. For example:

"I personally found the Introduction somewhat hard to parse"

That doesn't mean that the author has to make changes to the Introduction section. It's an editorial decision. It's up to the authors to determine whether the text should be changed so that the reader can understand it.

Last modified 4 years ago Last modified on Jul 30, 2015, 1:01:40 PM