These are the current (March 2008) draft guidelines for review in the RAI-ART.
These guidelines are liberally modeled from similar guidelines used by the GEN-ART review team and SIPPING WG review team. This review team most closely resembles that established for the APP area, in that only selected documents are reviewed.
The focus of this RAI-ART review team is early review of WG documents providing feedback on the technical direction of work items and identifying the need for potential cross area review earlier in the process. RAI-ART may also be asked to review documents from other areas based on either the use of RAI protocols (e.g., APP area documents) or the applicability to RAI protocols (e.g., SEC, Transport, OPS area documents).
Typically, documents to be reviewed would be those already accepted (or on the verge of acceptance) as WG documents within the RAI area. However, as mentioned, there may also be a need for RAI input on documents in other areas and individual documents within the RAI area (e.g., p-headers from other SDOs). The RAI-ART reviews should not slow down the progress of a document and should be done in parallel with any WG activity on the document.
The reviews are requested based on the joint decision of the document shepherd (WG chair or secretary) and the responsible RAI AD. The expectation is that the reviewer remains with the document at least through WGLC, as necessary, to provide any additional guidance. Although, there may be an initial request to review a document post-WGLC depending upon the type of issues raised during WGLC, this isn't expected to be the usual situation.
See also: FAQ, Reviewer list, Summary of Reviews
Reviews are done on an as needed basis, based on a request from a document shepherd or the responsible RAI AD (typically via email to the RAI-ART secretary). The expectation is that the decision to request a RAI-ART review is a joint decision between the document shepherd and the responsible RAI AD.
The process for reviewing Early documents:
The process for reviewing documents at WGLC time:
The Secretary assigns a reviewer (if none has been previously assigned) when a request comes in from a document shepherd or AD.
We expect the reviewer to be done before the end of Last Call.
The reviewer sends the review to the RAI area list
The reviewer also sends the review to the WG chairs & authors and the WG mailing list.
The process for reviewing documents at post-WGLC time:
The Secretary assigns a reviewer (if none has been previously assigned) when a request comes in from a document shepherd or AD.
We expect the reviewer to be done before the deadline set by the requestor (typically 2 weeks and sometimes 3 weeks for more complex documents).
The reviewer sends the review to the RAI area list
The reviewer also sends the review to the WG chairs & authors.
The RAI-Art review team is comprised of RAI WG chairs (or an individual designated by the WG chair) and other key RAI WG contributors.
Each review should include the following at the beginning of the review to clarify the intent of the review for the document editor/authors:
I am the assigned RAI-ART reviewer for draft-FOOBAR.txt.
For background on RAI-ART, please see the FAQ at <http://www.softarmor.com/rai/art/FAQ.html>.
Please resolve these comments along with any other comments you may receive.
I am the assigned RAI-ART reviewer for draft-FOOBAR.txt.
For background on RAI-ART, please see the FAQ at <http://www.softarmor.com/rai/art/FAQ.html>.
Please resolve these comments along with any other Last Call comments you may receive.
I am the assigned RAI-ART reviewer for draft-FOOBAR.txt.
For background on RAI-ART, please see the FAQ at <http://www.softarmor.com/rai/art/FAQ.html>.
Please wait for direction from your document shepherd or AD before posting a new version of the draft.
Each review should include a summary statement chosen from or adapted from the following list reflecting the reviewer's position on the overall state of the document, depending upon the type of review:
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.
The reviewers should focus on the technical aspects of the document such as basic architectural or security issues, cross-WG or cross-area (e.g., XML, DNS, security, etc.) impacts and technical nits. All substantive technical comments must be included in the public review and should appear in the beginning of the review. Wherever possible, comments should be written as suggestions for improvement rather than as simple criticism. Explicit references to prior work and prior IETF and/or WG discussion should be given.
Problems of form and format (such as IANA Considerations or incorrect references) and any editorial nits are of lesser importance, although they should be highlighted towards the end of the review. A review consisting only of copy-editing is not productive. If the reviewer feels that a draft is too badly written, it will be sufficient to say so with one or two examples. Detailed editorial nits should be documented as such and included at the end of the review.
The review should consider the following WG and/or topic
specific guidelines as appropriate:
[RFC4485] Guidelines for Authors of Extensions to the Session Initiation Protocol (for SIP, SIPPING and some SIMPLE documents)
[RFC4288] Media Type Specifications and Registration Procedures
[RFC3427] Change Process for the Session Initiation Protocol (SIP)
[RFC3265] Includes guidelines/template for new SIP event packages
as well as any other applicable architectural or procedural documents specific to the document topic, such as:
[RFC3424] IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation
[RFC4924] Reflections on Internet Transparency
The review may also consider the applicability of the following generally agreed IETF criteria as appropriate:
[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
[BCP104] Terminology for Describing Internet Connectivity
as well as any other applicable architectural or procedural documents. It is important that reviews give precise references to such criteria when relevant.
All reviews are posted on the IETF rai mailing list.
All reviews are also archived and publicly visible. The archive is here.