These are the current (March 2007) draft guidelines for WG document review in the SIPPING Working Group.
The guidelines were initially borrowed from the model that has proved fairly productive in the General Area and modified to suit the requirements for earlier and ongoing reviews within the working group.
See also: FAQ, Reviewer list, Summary of Reviews
The review process is initiated when documents reach maturity in the WG, with the earliest point expected to be a working group -00 draft.
The process for reviewing documents:
Reviewers are assigned by the WG chair(s) based on maturity of work.
The chair(s) name at least 1 reviewer per document (typically 2 and sometimes 3 for more complex documents), chosen more or less randomly (via a round robin process). For documents that have been reviewed before, the same reviewer is kept, if that person is still available.
The WG chairs serve as reviewers in most cases, since they are responsible for the PROTO write-up.
The reviewer should complete the review within the specified time period (typically 2-3 weeks).
The reviewer sends the review to the SIPPING WG mailing list, indicating the document title and type of review in the header, copying the document author(s)/editor(s) and WG chairs .
Rather than invent new guidelines, this document steals liberally from the gen-art review guidelines (which stole liberally from draft-carpenter-solutions-sirs-01), and adapts for the SIP guidelines.
Each review, roughly based on this template, should 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. [Note: This shouldn't typically be the case for documents within the SIPPING WG. In the case where some specifics are outside the reviewer's area of expertise, it is acceptable to make a statement upfront in the review that certain aspects should be reviewed by experts knowledgeable in a specific area (e.g., XML, MIBs, etc.). ].
The length of a review will vary greatly according to circumstances. All comments, including editorial 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. Per RFC 3427
Reviewers should review for all kinds of problems, from basic architectural or security issues, technical nits, problems of form and format (such as IANA Considerations or incorrect references), and editorial issues. 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. While the RFC editor can fix some fundamental problems in the final version, it does not reflect well on the WG to progress a document with these problems.
The review should apply the generally agreed guidelines for SIP Extensions:
[RFC4485] Guidelines for Authors of Extensions to the Session Initiation
as well as any other applicable architectural or procedural documents specific to the document topic (e.g., RFC 3265 for new event packages, etc.)
In the case of an expert review, this review template is used and these guidelines should be considered:
[RFC3427] [BCP 67] Guidelines for Authors of Extensions to the Session Initiation
The review should also apply generally agreed IETF criteria, as appropriate, 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
It is important that reviews give precise references to such criteria when relevant.
For documents being reviewed as part of WGLC, the following are important criteria to consider prior to the document being forwarded to the IESG:
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
The following summarizes the responsibilities of the author/editor and WG chairs in the review process, based upon the review summary statement. This is really a slight formalization of the normal WG process.
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.)
In the case of WGLC, this means the document is ready to be forwarded (by the WG chairs to the IESG), so the token is now with the WG chairs.
This draft is basically ready for publication, but has nits that should be fixed before publication.
Draft needs to be revised (within 2 weeks, unless otherwise agreed).
This draft is on the right track but has open issues, described in the review.
Issues raised in this category indicate the need for some reasonable dialog amongst the reviewers and authors, with subsequent resolution posted to the WG mailing list for approval prior to a new version of the document being produced.
This draft has serious issues, described in the review, and needs to be rethought.
Issues raised in this category trigger the need for in-depth discussion amongst the reviewer(s) and authors.
If issues don't appear to resolve readily amongst the reviewers and authors or on the mailing list, a design team may be formed and conference calls scheduled to resolve the issues.
This draft has very fundamental issues, described in the review, and further work is not recommended.
This review classification requires discussion amongst the WG chairs, reviewers and authors (and possibly the AD) to determine the way forward, with the proposed resolution posted to the mailing list for any additional feedback.
Unfortunately, I don't have the expertise to review this draft.
If all the reviews (from the 2 or 3 reviewers) were in this category, the WG chairs need to find an expert to complete the review.
As with the previous category, the resolution of the issues should be posted to the WG mailing list for approval prior to a new version being produced.
All reviews are posted on the IETF SIPPING WG mailing list.
All reviews are also archived and publicly visible. The archive is here.