These are the current (December 2006) draft guidelines for review in the GEN-ART.
The guidelines initially focused on the model that had proven fairly productive in the Ops Directorate: Quick review close to telechat time, to advise the AD on issues that remain serious and has evolved to review the majority of documents at the time of IETF LC, with a few documents reviewed at the request of ADs even earlier.
See also: FAQ, Reviewer list, Summary of Reviews
Review is typically done at Last Call, when the document appears on the IESG agenda, or both. In addition, some documents are reviewed even earlier based on a request from the AD.
The process for reviewing Early documents:
The process for reviewing documents at Last Call:
The Secretary assigns a reviewer around the time of the Last Call announcement – typically on Thursday evenings.
We expect the reviewer to be done before the end of Last Call.
The reviewer sends the review to the Gen-ART list
The reviewer also sends the review to the AD, WG chairs & authors, and optionally to the WG mailing list. Since IETF Last Call comments are commonly sent to the IETF discussion list, the reviewer may also choose to do that; in any case the review will be public.
The process for reviewing documents when they appear on the IESG agenda:
Secretary checks the IESG agenda one week before the IESG telechat. The agenda is typically finalized Thursday evening EDT, with late agenda items sometimes being added on Friday morning, thus the assignments are out either late Thursday evening or early Friday morning (EDT).
For documents reviewed at Last Call, a new review is only asked for if the document is revised or issues resolved.
The Secretary names a reviewer per document, more or less randomly. For documents that have been reviewed before, the same reviewer is kept, if that person is still available.
Reviewers send their review to the Gen-ART list no later than COB (i.e., 8 PM CDT) the Tuesday before the telechat (earlier is better!)
Reviews should be copied to authors, responsible ADs and WG chairs, unless the review finds no issues. Also, including a link to the FAQ in the email has proved essential for the recipients of the review in understanding the context, especially since Gen-ART review is a new experience for the average author.
If the AD concludes that the concerns raised by the reviewer warrant blocking the document, the AD will do so.
The telechats are every other Thursday, with the first telechat for 2007 on January 11th.
Except for skipping a telechat around the IETF meetings or Holidays, these rarely change.
Rather than invent new guidelines, this document steals liberally from draft-carpenter-solutions-sirs-01, and adapts for the special "late, quick review" case and the General area's questions.
Each review must include either of the two variants at the beginning of the review:
I am the assigned Gen-ART reviewer for draft-FOOBAR.txt.
For background on Gen-ART, please see the FAQ at <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Please resolve these comments along with any other comments you may receive.
I am the assigned Gen-ART reviewer for draft-FOOBAR.txt.
For background on Gen-ART, please see the FAQ at <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Please resolve these comments along with any other Last Call comments you may receive.
I am the assigned Gen-ART reviewer for draft-FOOBAR.txt.
For background on Gen-ART, please see the FAQ at <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Please wait for direction from your document shepherd or AD before posting a new version of the draft.
Each review must include a summary statement chosen from or adapted from the following list:
This draft is ready for publication as a [type] RFC, where [type] is Informational, Experimental, etc. (In some cases, the review might recommend publication as a different [type] than requested by the author.)
This draft is basically ready for publication, but has nits that should be fixed before publication.
This draft is on the right track but has open issues, described in the review.
This draft has serious issues, described in the review, and needs to be rethought.
This draft has very fundamental issues, described in the review, and further work is not recommended.
Unfortunately, I don't have the expertise to review this draft.
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.
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
[RFC2223] Instructions to RFC Authors
[BCP26] Guidelines for Writing an IANA Considerations Section in RFCs
[RFC3552] 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.
Of special interest to the GEN area (because it's no area's special interest) is:
Clear description of why the document or protocol is useful to the Internet
Adherence to IETF formalities such as capitalized MUST/SHOULD (ID-Nits)
Useful and reasonable IANA considerations
Correct dependencies for normative references
That it's written in reasonably clear English
All reviews are posted on the IETF gen-art mailing list.
All reviews are also archived and publicly visible. The archive is here.