Directorates and Area Review Teams (ART) are essential to ensure a wide but also detailed review of IETF documents. The reviews done by those teams ensure:
A side-effect is also to relieve part of the IESG work load.
Finally, it is also an opportunity for the ART reviewers to learn about other areas, to understand better the publication process, and also build a human network with the interactions with other reviewers and documents authors. It is often a step towards a leadership position within the IETF.
Review teams is used below to refer to either a Directorate or Area Review Teams. Here is an updated list of active review directorates: https://datatracker.ietf.org/review/
This page describes the general process that is common for all review teams. Each area also has its own specific page:
Another important links is the collected list of typical issues by area Expert Topics.
Reviews are managed using a specific tool. Reviewers can log in to the tool with their usual datatracker credentials here: https://datatracker.ietf.org/group/<''review team''>/reviews/
See also:
Documents are typically assigned to a reviewer during IETF Last Call. The documents may be re-reviewed once they appear on a Telechat agenda.
Documents may also be reviewed at the request of ADs prior to IETF Last Call.
The general assignment process:
The process for reviewing Early Review documents:
The process for reviewing documents at IETF Last Call:
The IESG Telechats are every other Thursday, with the agenda finalized on the Thursday evening one week prior to the IESG evaluation during the Telechat. The process for reviewing documents when they appear on the IESG agenda:
Each review must include one of the following at the beginning of the review, or an equivalent text if specified by the relevant specific page above. This text is pre-entered if the review is completed in the Tool.
For Early reviews: I am the assigned review team reviewer for this draft. For background on review team, please see the FAQ at TODO. Please resolve these comments along with any other comments you may receive.
For IETF Last Call reviews: I am the assigned review team reviewer for this draft. The review team reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at TODO.
For IESG Evaluation reviews: I am the assigned review team reviewer for this draft. The review team reviews all IETF documents being processed by the IESG. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at TODO.
Each review must include a summary statement chosen from or adapted from the following list:
The length of a review will vary greatly according to circumstances, and it is acceptable for purely editorial comments to be sent privately if it's obvious that the document will have to be substantially revised anyway. All substantive comments must be included in the public review. Wherever possible, they should be written as suggestions for improvement rather than as simple criticism. Explicit references to prior work and prior IETF discussion should be given.
For specific topics to keep in mind while reviewing, depending on the ''review team'', refer to each specific page or to the Expert Topics. However, in general, reviewers should review for all kinds of problems, from basic architectural or security issues, Internet-wide impact, technical nits, problems of form and format (such as IANA Considerations or incorrect references), and editorial issues. Since these reviews are on documents that are supposed to be finished, the review should consider "no issue too small" - but cover the whole range from the general architectural level to the editorial level. However, a review which consists only of copy-editing is not productive. If the reviewer feels that a draft is too badly written to advance, it will be sufficient to say so with one or two examples.
The review should apply generally agreed IETF criteria, such as
RFC1958 - The Architectural Principles of the Internet
RFC3426 - General Architectural and Policy Considerations
RFC3439 - Some Internet Architectural Guidelines and Philosophy
NITS The "I-D Nits" document maintained by the IESG
BCP26 Guidelines for Writing an IANA Considerations Section in RFCs
BCP72 Guidelines for Writing RFC Text on Security Considerations
as well as any other applicable architectural or procedural documents. It is important that reviews give precise references to such criteria when relevant.
When is a reviewer likely to flag an issue as '''major''', which may well
lead to a DISCUSS ballot in the IESG unless it's fixed in advance?
The IESG's own guidelines are at [https://www.ietf.org/iesg/statement/discuss-criteria.html]. Reviewers (or authors) can put themselves in the AD shoes. Would you definitely hold up the document for this (i.e. a solid DISCUSS)? Would publishing it as-is be actively misleading or harmful? Then it's major.
Would you possibly place a DISCUSS, which you would very likely drop as soon as an author or the sponsoring AD explained the point or said "sure, we'll fix that"? Or would you simply issue a COMMENT and ballot No Objection? Then it's minor.
Are you just saving some work for the RFC Editor? Then it's a nit.
However, all these are judgment calls in the end.
The following aliases can be helpful in getting the reviews to the right targets, replacing draftname by draft-ietf-wg-topic (without -xx version)
| draftname@ietf.org | Draft authors (for now, could change) |
| draftname.authors@ietf.org | Draft authors |
| draftname.chairs@ietf.org | WG Chairs (if the draft is a WG draft) |
| draftname.notify@ietf.org | The addresses entered into the tracker's email notification field for the draft |
| draftname.ad@ietf.org | The AD(s) of the WG area, if the draft has gone to the IESG |
| draftname.all@ietf.org | All of the above, merged into one alias |
All reviews done by the datatracker tool are also sent to the ''review team'' mailing list, and also to the authors, ADs, and/or WG chairs/Document Shepherds. Reviewers may also send the reviews to the IETF discussion list, which is done by default if the Review Tool mentioned below is used to submit reviews.
All reviews are archived. They are visible in the mailing list archive, along with any subsequent discussion copied to the list.
The text in this page was shamelessly taken and adapted from the Gen-ART wiki page.