1. SIRs, or AIRs, or something draft-carpenter-solution-sirs-01.txt Brian Carpenter without consulting my co-author Dave Crocker IETF 57, 07/03

2. Terminology Senior IETF Reviewer –working title, acronym has implications Agreed IETF Reviewer –less loaded acronym? Careful Additional Review of Drafts –“carding” is the process of preparing fibres for spinning and weaving

3. Problems targetted Perception of concentration of power Lack of quality audit throughout IETF process –most drafts are not widely read –reviews are often lacking or late –Last Calls generate little response IESG receives drafts with serious problems –  IESG overload and delay Late surprises (IETF-wide issues detected very late in process) Reviewers get little credit.

4. Basic proposal Create a recognized team of IETF reviewers –Team is created and refreshed by a community process Have all drafts reviewed early (-00 version), as they mature (main options fixed), and late (just before IESG submission) –Reviews are published –Reviews cover both “local” and IETF-wide issues –Aim is help authors and WGs produce high quality drafts without late surprises Build trust in this process, so that IESG (and RFC Editor) trust these reviews

5. What doesn’t change The standards process. –Both IESG and RFC Editor retain their power of decision. –But if they have any sense, they will use the reviews as their decision support system. –Missing, conflicting or negative reviews will trigger thorough IESG review and cause delay. –Strongly in the authors’ interest to achieve positive reviews.

6. Creating the team ~200 RFCs/year –At least three review cycles per draft –At least three reviewers per draft –  1800 reviews per year  200 reviewers would be appropriate Initial suggestion is to enrol –current IAB members –former IAB and IESG members, and former WG Chairs –current MIB Doctors –members of existing IETF Directorates –all authors of at least three RFCs

7. Increasing and maintaining the team Have an open nominations season once a year Have existing reviewers vote in the nominees Reviewers who never review leave the team –Reviewing is a recognized function, but it is not resumé candy For extreme problems, have a recall mechanism for ejecting reviewers

8. Triggering reviews WG drafts –each WG decides (for example, decides that the WG chair triggers reviews) –reviewers must include both subject matter experts and IETF generalists Individual drafts –author triggers reviews

9. What’s in a review One sentence recommendation (ready/needs work/broken) Technical review Review against same criteria as IESG uses today –general principles RFCs –specific guidelines (IANA, Security etc) –ID Nits Editorial review may be private, but everything substantive is public and not anonymous.

10. Mechanics Need a web site to help WGs and authors find reviewers. Experimental version at http://graybeards.net/sirs/ Need web tooling to submit reviews and have them hyperlinked to the draft. Ideally, http://sirs.ietf.org/draft-carpenter-solution-sirs would lead to a page with links to the latest version of the draft and links to all the reviews. –with a link from the ID tracker to this page

11. Comments welcome now, or on some mailing list