doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc7735.txt b/doc/rfc/rfc7735.txt
new file mode 100644
index 0000000..4f420ce
--- /dev/null
+++ b/doc/rfc/rfc7735.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         R. Sparks
+Request for Comments: 7735                                        Oracle
+Category: Informational                                       T. Kivinen
+ISSN: 2070-1721                                            INSIDE Secure
+                                                            January 2016
+
+
+                     Tracking Reviews of Documents
+
+Abstract
+
+   Several review teams ensure specific types of review are performed on
+   Internet-Drafts as they progress towards becoming RFCs.  The tools
+   used by these teams to assign and track reviews would benefit from
+   tighter integration to the Datatracker.  This document discusses
+   requirements for improving those tools without disrupting current
+   work flows.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7735.
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Sparks & Kivinen              Informational                     [Page 1]
+
+RFC 7735                     Review Tracking                January 2016
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Overview of Current Workflows . . . . . . . . . . . . . . . .   3
+   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
+     3.1.  Secretariat Focused . . . . . . . . . . . . . . . . . . .   5
+     3.2.  Review-Team Secretary Focused . . . . . . . . . . . . . .   5
+     3.3.  Reviewer Focused  . . . . . . . . . . . . . . . . . . . .   8
+     3.4.  Review Requester and Consumer Focused . . . . . . . . . .  10
+     3.5.  Statistics Focused  . . . . . . . . . . . . . . . . . . .  11
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
+   5.  Informative References  . . . . . . . . . . . . . . . . . . .  12
+   Appendix A.  A Starting Point for Django Models Supporting the
+                Review Tool  . . . . . . . . . . . . . . . . . . . .  14
+   Appendix B.  Suggested Features Deferred for Future Work  . . . .  15
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16
+
+1.  Introduction
+
+   As Internet-Drafts are processed, reviews are requested from several
+   review teams.  For example, the General Area Review Team (Gen-ART)
+   and the Security Directorate (SecDir) perform reviews of documents
+   that are in IETF Last Call.  Gen-ART always performs a follow-up
+   review when the document is scheduled for an IESG Telechat.  SecDir
+   usually performs a follow-up review, but the SecDir secretary may
+   choose not to request that follow-up if any issues identified at Last
+   Call are addressed and there are otherwise no major changes to the
+   document.  These teams also perform earlier reviews of documents on
+   demand.  There are several other teams that perform similar services,
+   often focusing on specific areas of expertise.
+
+   The secretaries of these teams manage a pool of volunteer reviewers.
+   Documents are assigned to reviewers, taking various factors into
+   account.  For instance, a reviewer will not be assigned a document
+   for which he is an author or shepherd.  Reviewers are given a
+   deadline, usually driven by the end of Last Call or an IESG Telechat
+   date.  The reviewer sends each completed review to the team's mailing
+   list and to any other lists that are relevant for the document being
+   reviewed.  Often, a thread ensues on one or more of those lists to
+   resolve any issues found in the review.
+
+   The secretaries and reviewers from several teams are using a tool
+   developed and maintained by Tero Kivinen.  Much of its design
+   predates the modern Datatracker.  The application currently keeps its
+   own data store and learns about documents needing review by
+   inspecting Datatracker and tools.ietf.org pages.  Most of those pages
+   are easy to parse, but the Last Call pages, in particular, require
+
+
+
+Sparks & Kivinen              Informational                     [Page 2]
+
+RFC 7735                     Review Tracking                January 2016
+
+
+   some effort.  Tighter integration with the Datatracker would simplify
+   the logic used to identify documents that are ready for review, make
+   it simpler for the Datatracker to associate reviews with documents,
+   and allow users to reuse their Datatracker credentials.  It would
+   also make it easier to detect other potential review-triggering
+   events, such as a document entering Working Group (WG) Last Call or
+   when an RFC's standard level is being changed without revising the
+   RFC.  Tero currently believes this integration is best achieved by a
+   new implementation of the tool.  This document captures requirements
+   for that reimplementation, with a focus on the workflows that the new
+   implementation must take care not to disrupt.  It also discusses new
+   features, including changes suggested for the existing tool at its
+   issue tracker [art-trac].
+
+   For more information about the various review teams, see the
+   following references.
+
+          +-------------------------------+---------------------+
+          | General Area Review Team      | [Gen-ART] [RFC6385] |
+          | Security Directorate          | [SecDir]            |
+          | Applications Area Directorate | [AppsDir]           |
+          | Operations Area Directorate   | [OPS-dir]           |
+          | Routing Area Directorate      | [RTG-dir]           |
+          | MIB Doctors                   | [MIBdoctors]        |
+          | YANG Doctors                  | [YANGdoctors]       |
+          +-------------------------------+---------------------+
+
+2.  Overview of Current Workflows
+
+   This section gives a high-level overview of how the review team
+   secretaries and reviewers use the existing tool.  It is not intended
+   to be comprehensive documentation of how review teams operate.
+   Please see the references for those details.
+
+   For many teams, the team's secretary periodically (typically once a
+   week) checks the tool for documents it has identified as ready for
+   review.  The tool compiles a list from Last Call announcements and
+   IESG Telechat agendas.  The secretary creates a set of assignments
+   from this list and enters them into the reviewer pool, choosing the
+   reviewers in roughly a round-robin order.  That order can be
+   perturbed by several factors.  Reviewers have different levels of
+   availability.  Some are willing to review multiple documents a month.
+   Others may only be willing to review a document every other month.
+   The assignment process takes exceptional conditions such as reviewer
+   vacations into account.  Furthermore, secretaries are careful not to
+   assign a document to a reviewer that is an author, shepherd,
+   responsible WG chair, or has some other already existing association
+   with the document.  The preference is to get a reviewer with a fresh
+
+
+
+Sparks & Kivinen              Informational                     [Page 3]
+
+RFC 7735                     Review Tracking                January 2016
+
+
+   perspective.  The secretary may discover reasons to change
+   assignments while going through the list of documents.  In order to
+   not cause a reviewer to make a false start on a review, the
+   secretaries complete the full list of assignments before sending
+   notifications to anyone.  This assignment process can take several
+   minutes and it is possible for new Last Calls to be issued while the
+   secretary is making assignments.  The secretary typically checks to
+   see if new documents are ready for review just before issuing the
+   assignments and updates the assignments if necessary.
+
+   Some teams operate in more of a review-on-demand model.  The Routing
+   Area Directorate (RTG-dir), for example, primarily initiates reviews
+   at the request of a Routing AD.  They may also start an early review
+   at the request of a WG chair.  In either case, the reviewers are
+   chosen manually from the pool of available reviewers driven by
+   context rather than using a round-robin ordering.
+
+   The issued assignments are either sent to the review team's email
+   list or are emailed directly to the assigned reviewer.  The
+   assignments are reflected in the tool.  For those teams handling
+   different types of reviews (Last Call vs. Telechat, for example), the
+   secretary typically processes the documents for each type of review
+   separately, and potentially with different assignment criteria.  In
+   Gen-ART, for example, the Last Call reviewer for a document will
+   almost always get the follow-up Telechat review assignment.
+   Similarly, SecDir assigns any re-reviews of a document to the same
+   reviewer.  Other teams may choose to assign a different reviewer.
+
+   Reviewers discover their assignments through email or by looking at
+   their queue in the tool.  The secretaries for some teams (such as the
+   OPS-dir and RTG-dir) insulate their team members from using the tool
+   directly.  These reviewers only work through the review team's email
+   list or through direct email.  On teams that have the reviewers use
+   the tool directly, most reviewers only check the tool when they see
+   they have an assignment via the team's email list.  A reviewer has
+   the opportunity to reject the assignment for any reason.  While the
+   tool provides a way to reject assignments, reviewers typically use
+   email to coordinate rejections with the team secretary.  The
+   secretary will find another volunteer for any rejected assignments.
+   The reviewer can indicate that the assignment is accepted in the tool
+   before starting the review, but this feature is rarely used.
+
+   The reviewer sends a completed review to the team's email list or
+   secretary, as well as any other lists relevant to the review, and
+   usually the draft's primary email alias.  For instance, many Last
+   Call reviews are also sent to the IETF general list.  The teams
+   typically have a template format for the review.  Those templates
+   usually start with a summary of the conclusion of the review.
+
+
+
+Sparks & Kivinen              Informational                     [Page 4]
+
+RFC 7735                     Review Tracking                January 2016
+
+
+   Typical summaries are "ready for publication" or "on the right track
+   but has open issues".  The reviewer (or in the case of teams that
+   insulate their reviewers, the secretary) uses the tool to indicate
+   that the review is complete, provides the summary, and has an
+   opportunity to provide a link to the review in the archives.  Note,
+   however, that having to wait for the document to appear in the
+   archive to know the link to paste into the tool is a significant
+   enough impedance that this link is often not provided by the
+   reviewer.  The SecDir secretary manually collects these links from
+   the team's email list and adds them to the tool.
+
+   Occasionally, a document is revised between when a review assignment
+   is made and when the reviewer starts the review.  Different teams can
+   have different policies about whether the reviewer should review the
+   assigned version or the current version.
+
+3.  Requirements
+
+3.1.  Secretariat Focused
+
+   o  The Secretariat must be able to configure secretaries and
+      reviewers for review teams (by managing Role records).
+
+   o  The Secretariat must be able to perform any secretary action on
+      behalf of a review team secretary (and thus, must be able to
+      perform any reviewer action on behalf of the reviewer).
+
+3.2.  Review-Team Secretary Focused
+
+   o  A secretary must be able to see what documents are ready for a
+      review of a given type (such as a Last Call review).
+
+   o  A secretary must be able to assign reviews for documents that may
+      not have been automatically identified as ready for a review of a
+      given type.  (In addition to being the primary assignment method
+      for teams that only initiate reviews on demand, this allows the
+      secretary to work around errors and handle special cases,
+      including early review requests.)
+
+   o  A secretary must be able to work on and issue a set of assignments
+      as an atomic unit.  No assignment should be issued until the
+      secretary declares the set of assignments complete.
+
+   o  The tool must support teams that have multiple secretaries.  The
+      tool should warn secretaries that are simultaneously working on
+      assignments and protect against conflicting assignments being
+      made.
+
+
+
+
+Sparks & Kivinen              Informational                     [Page 5]
+
+RFC 7735                     Review Tracking                January 2016
+
+
+   o  It must be easy for the secretary to discover that more documents
+      have become ready for review while working on an assignment set.
+
+   o  The tool should make preparing the assignment email to the team's
+      email list easy.  For instance, the tool could prepare the
+      message, give the secretary an opportunity to edit it, and handle
+      sending it to the team's email list.
+
+   o  It must be possible for a secretary to indicate that the review
+      team will not provide a review for a document (or a given version
+      of a document).  This indication should be taken into account when
+      presenting the documents that are ready for a review of a given
+      type.  This will also make it possible to show on a document's
+      page that no review is expected from this team.
+
+   o  A secretary must be able to easily see who the next available
+      reviewers are, in order.
+
+   o  A secretary must be able to edit a reviewer's availability, both
+      in terms of frequency, not-available-until-date, and skip-next-
+      n-assignments.  (See the description of these settings in
+      Section 3.3.)
+
+   o  The tool should make it easy for the secretary to see any team
+      members that have requested to review a given document when it
+      becomes available for review.
+
+   o  The tool should make it easy for the secretary to identify that a
+      reviewer is already involved with a document.  The current tool
+      allows the secretary to provide a regular expression to match
+      against the document name.  If the expression matches, the
+      document is not available for assignment to this reviewer.  For
+      example, Tero will not be assigned documents matching '^draft-
+      (kivinen|ietf-tcpinc)-.*$'.  The tool should also take any roles,
+      such as document shepherd, that the Datatracker knows about into
+      consideration.
+
+   o  The tool should make it easy for the secretary to see key features
+      of a document ready for assignment, such as its length, its
+      authors, the group and area it is associated with, its title and
+      abstract, its states (such as IESG or WG states), and any other
+      personnel (such as the shepherd and reviewers already assigned
+      from other teams) involved in the draft.
+
+   o  The tool must make it easy for the secretary to detect and process
+      re-review requests on the same version of a document (such as when
+      a document has an additional Last Call only to deal with new IPR
+      information).
+
+
+
+Sparks & Kivinen              Informational                     [Page 6]
+
+RFC 7735                     Review Tracking                January 2016
+
+
+   o  Common operations to groups of documents should be easy for the
+      secretary to process as a group with a minimum amount of
+      interaction with the tool.  For instance, it should be possible to
+      process all of the documents described by the immediately
+      preceding bullet with one action.  Similarly, for teams that
+      assign re-reviews to the same reviewer, issuing all re-review
+      requests should be a simple action.
+
+   o  A secretary must be able to see which reviewers have outstanding
+      assignments.
+
+   o  The tool must make it easy for the secretary to see the result of
+      previous reviews from this team for a given document.  In SecDir,
+      for example, if the request is for a revision that has only minor
+      differences and the previous review result was "Ready", a new
+      assignment will not be made.  If the given document replaces one
+      or more other prior documents, the tool must make it easy for the
+      secretary to see the results of previous reviews of the replaced
+      documents.
+
+   o  The tool must make it easy for the secretary to see the result of
+      previous reviews from this team for all documents across
+      configurable, recent periods of time (such as the last 12 months).
+      A secretary of the RTG-dir, for example, would use this result to
+      aid in the manual selection of the next reviewer.
+
+   o  The tools must make it easy for the secretary to see the recent
+      performance of a reviewer while making an assignment (see
+      Section 3.5).  This allows the secretary to detect overburdened or
+      unresponsive volunteers earlier in the process.
+
+   o  A secretary must be able to configure the tool to remind them to
+      follow up when actions are due.  (For instance, a secretary could
+      receive email when a review is about to become overdue.)
+
+   o  A secretary must be able to assign multiple reviewers to a given
+      draft at any time.  In particular, a secretary must be able to
+      assign an additional reviewer when an original reviewer indicates
+      their review is likely to be only partially complete.
+
+   o  A secretary must be able to withdraw a review assignment.
+
+   o  A secretary must be able to perform any reviewer action on behalf
+      of the reviewer.
+
+   o  A secretary must be able to configure the review team's set of
+      reviewers (by managing Role records for the team).
+
+
+
+
+Sparks & Kivinen              Informational                     [Page 7]
+
+RFC 7735                     Review Tracking                January 2016
+
+
+   o  Information about a reviewer must not be lost when a reviewer is
+      removed from a team.  (Frequently, reviewers come back to teams
+      later.)
+
+   o  A secretary must be able to delegate secretary capabilities in the
+      tool (similar to how a working group chair can assign a Delegate).
+      This allows review teams to self-manage secretary vacations.
+
+3.3.  Reviewer Focused
+
+   o  A reviewer must be able to indicate availability, both in
+      frequency of reviews and as "not available until this date".  The
+      current tool speaks of frequency in these terms:
+
+      -  Assign at maximum one new review per week
+
+      -  Assign at maximum one new review per fortnight
+
+      -  Assign at maximum one new review per month
+
+      -  Assign at maximum one new review per two months
+
+      -  Assign at maximum one new review per quarter
+
+   o  Reviewers must be able to indicate hiatus periods.  Each period
+      may be either "soft" or "hard".
+
+      -  A hiatus must have a start date.  It may have an end date or it
+         may be indefinite.
+
+      -  During a hiatus, the reviewer will not be included in the
+         normal review rotation.  When a provided end date is reached,
+         the reviewer will automatically be included in the rotation in
+         their usual order.
+
+      -  During a "soft" hiatus, the reviewer must not be assigned new
+         reviews but is expected to complete existing assignments and do
+         follow-up reviews.
+
+      -  During a "hard" hiatus, the reviewer must not be assigned any
+         new reviews and the secretary must be prompted to reassign any
+         outstanding or follow-up reviews.
+
+   o  Reviewers must be able to indicate that they should be skipped the
+      next "n" times they would normally have received an assignment.
+
+
+
+
+
+
+Sparks & Kivinen              Informational                     [Page 8]
+
+RFC 7735                     Review Tracking                January 2016
+
+
+   o  Reviewers must be able to indicate that they are transitioning to
+      inactive and provide a date for the end of the transition period.
+      During this transition time, the reviewer must not be assigned new
+      reviews but is expected to complete outstanding assignments and
+      follow-up reviews.  At the end of the transition period, the
+      secretary must be prompted to reassign any outstanding or follow-
+      up reviews.  (This allows review-team members that are taking on
+      AD responsibility to transition gracefully to an inactive state
+      for the team.)
+
+   o  Both the reviewer and the secretary will be notified by email of
+      any modifications to a reviewer's availability.
+
+   o  A reviewer must be able to easily discover new review assignments.
+      (The tool might send email directly to an assigned reviewer in
+      addition to sending the set of assignments to the team's email
+      list.  The tool might also use the Django Message framework to let
+      a reviewer that's logged into the Datatracker know a new review
+      assignment has been made.)
+
+   o  Reviewers must be able to see their current set of outstanding
+      assignments, completed assignments, and rejected assignments.  The
+      presentation of those sets should either be separate or, if
+      combined, the sets should be visually distinct.
+
+   o  A reviewer should be able to request to review a particular
+      document.  The draft may be in any state: available and
+      unassigned; already assigned to another reviewer; or not yet
+      available.
+
+   o  A reviewer must be able to reject a review assignment, optionally
+      providing the secretary with an explanation for the rejection.
+      The tool will notify the secretary of the rejection by email.
+
+   o  A reviewer must be able to indicate that they have accepted and
+      are working on an assignment.
+
+   o  A reviewer must be able to indicate that a review is only
+      partially completed and ask the secretary to assign an additional
+      reviewer.  The tool will notify the secretary of this condition by
+      email.
+
+   o  It should be possible for a reviewer to reject or accept a review
+      either by using the tool's web interface or by replying to the
+      review assignment email.
+
+   o  It must be easy for a reviewer to see when each assigned review is
+      due.
+
+
+
+Sparks & Kivinen              Informational                     [Page 9]
+
+RFC 7735                     Review Tracking                January 2016
+
+
+   o  A reviewer must be able to configure the tool to remind them when
+      actions are due.  (For instance, a reviewer could receive email
+      when a review is about to become overdue).
+
+   o  A reviewer must be able to indicate that a review is complete,
+      capturing where the review is in the archives and the high-level,
+      review-result summary.
+
+   o  It must be possible for a reviewer to clearly indicate which
+      version of a document was reviewed.  Documents are sometimes
+      revised between when a review was assigned and when it is due.
+      The tool should note the current version of the document and
+      highlight when the review is not for the current version.
+
+   o  It must be easy for a reviewer to submit a completed review.
+
+      -  The current workflow, where the reviewer sends email to the
+         team's email list (possibly copying other lists) and then
+         indicates where to find that review, must continue to be
+         supported.  The tool should make it easier to capture the link
+         to review in the team's email list archives (perhaps by
+         suggesting links based on a search into the archives).
+
+      -  The tool should allow the reviewer to enter the review into the
+         tool via a web form (either as directly provided text or
+         through a file-upload mechanism).  The tool will ensure the
+         review is posted to the appropriate lists and will construct
+         the links to those posts in the archives.
+
+      -  The tool could also allow the reviewer to submit the review to
+         the tool by email (perhaps by replying to the assignment).  The
+         tool would then ensure the review is posted to the appropriate
+         lists.
+
+3.4.  Review Requester and Consumer Focused
+
+   o  It should be easy for an AD or group chair to request any type of
+      review, but particularly an early review, from a review team.
+
+   o  It should be possible for that person to withdraw a review
+      request.
+
+   o  It must be easy to find all reviews of a document when looking at
+      the document's main page in the Datatracker.  The reference to the
+      review must make it easy to see any responses to the review on the
+      email lists it was sent to.  If a document "replaces" one or more
+      other documents, reviews of the replaced documents should be
+      included in the results.
+
+
+
+Sparks & Kivinen              Informational                    [Page 10]
+
+RFC 7735                     Review Tracking                January 2016
+
+
+   o  It must be easy to find all reviews of a document when looking at
+      search result pages and other lists of documents, such as the
+      documents on an IESG Telechat agenda.
+
+3.5.  Statistics Focused
+
+   o  It must be easy to see the following across all teams, a given
+      team, or a given reviewer, and independently across all time or
+      across configurable recent periods of time:
+
+      -  how many reviews have been completed
+
+      -  how many reviews are in progress
+
+      -  how many in progress reviews are late
+
+      -  how many completed reviews were late
+
+      -  how many reviews were not completed at all
+
+      -  average time to complete reviews (from assignment to
+         completion)
+
+   o  It must be easy to see the following for all teams, for a given
+      team, or for a given reviewer, across all time or across
+      configurable recent periods:
+
+      -  total counts of reviews in each review state (done, rejected,
+         etc.)
+
+      -  total counts of completed reviews by result (ready, ready with
+         nits, etc.)
+
+   o  The above statistics should also be calculated reflecting the size
+      of the documents being reviewed (such as using the number of pages
+      or words in the documents).
+
+   o  Where applicable, statistics should take reviewer hiatus periods
+      into account.
+
+   o  Access to the above statistics must be easy to configure.  Access
+      will be initially limited as follows:
+
+      -  The Secretariat and ADs can see any statistic.
+
+      -  A team secretary can see any statistics for that team.
+
+
+
+
+
+Sparks & Kivinen              Informational                    [Page 11]
+
+RFC 7735                     Review Tracking                January 2016
+
+
+      -  A reviewer can see any team aggregate statistics or their own
+         reviewer-specific statistics.
+
+   o  Where possible, the above statistics should be visible as a time-
+      series graph.
+
+   o  The implementation should anticipate future enhancements that
+      would allow ADs to indicate their position was informed by a given
+      review.  Such enhancements would allow reporting correlations
+      between reviews and documents that receive one or more
+      "discusses".  However, implementing these enhancements is not part
+      of the current project.
+
+4.  Security Considerations
+
+   This document discusses requirements for tools that assist review
+   teams.  These requirements do not affect the security of the Internet
+   in any significant fashion.  The tools themselves have authentication
+   and authorization considerations (team secretaries will be able to do
+   different things than reviewers).
+
+5.  Informative References
+
+   [AppsDir]  IETF, "Applications Area Directorate Review Process",
+              <http://trac.tools.ietf.org/area/app/trac/wiki/
+              AppsDirReview>.
+
+   [art-trac] IETF, "Area Review Team Tool: {1} Active Tickets",
+              <https://wiki.tools.ietf.org/tools/art/trac/report/1>.
+
+   [Gen-ART]  IETF, "General Area: General Area Review Team (GEN-ART)
+              Guidelines",
+              <http://trac.tools.ietf.org/area/gen/trac/wiki>.
+
+   [MIBdoctors]
+              IETF, "MIB Doctors",
+              <http://www.ietf.org/iesg/directorate/mib-doctors.html>.
+
+   [OPS-dir]  IETF, "OPS Directorate (OPS-DIR)",
+              <https://svn.tools.ietf.org/area/ops/trac/wiki/
+              Directorates>.
+
+   [RFC6385]  Barnes, M., Doria, A., Alvestrand, H., and B. Carpenter,
+              "General Area Review Team (Gen-ART) Experiences",
+              RFC 6385, DOI 10.17487/RFC6385, October 2011,
+              <http://www.rfc-editor.org/info/rfc6385>.
+
+
+
+
+
+Sparks & Kivinen              Informational                    [Page 12]
+
+RFC 7735                     Review Tracking                January 2016
+
+
+   [RTG-dir]  IETF, "Routing Area Directorate Wiki Page",
+              <http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>.
+
+   [SecDir]   IETF, "Security Directorate",
+              <http://trac.tools.ietf.org/area/sec/trac/wiki/
+              SecurityDirectorate>.
+
+   [YANGdoctors]
+              IETF, "YANG Doctors",
+              <http://www.ietf.org/iesg/directorate/yang-doctors.html>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks & Kivinen              Informational                    [Page 13]
+
+RFC 7735                     Review Tracking                January 2016
+
+
+Appendix A.  A Starting Point for Django Models Supporting the Review
+             Tool
+
+ from django.db import models
+ from ietf.doc.models import Document
+ from ietf.person.models import Email
+ from ietf.group.models import Group, Role
+
+ from ietf.name.models import NameModel
+
+ class ReviewRequestStateName(NameModel):
+     """ Requested, Accepted, Rejected, Withdrawn, Overtaken By Events,
+         No Response , Completed  """
+
+ class ReviewTypeName(NameModel):
+     """ Early Review, Last Call, Telechat """
+
+ class ReviewResultName(NameModel):
+     """Almost ready, Has issues, Has nits, Not Ready,
+        On the right track, Ready, Ready with issues,
+        Ready with nits, Serious Issues"""
+
+ class Reviewer(models.Model):
+     """
+     These records associate reviewers with review teams and keep track
+     of admin data associated with the reviewer in the particular team.
+     There will be one record for each combination of reviewer and team.
+     """
+     role        = models.ForeignKey(Role)
+     frequency   = models.IntegerField(help_text=
+                                   "Can review every N days")
+     available   = models.DateTimeField(blank=True,null=True, help_text=
+                         "When will this reviewer be available again")
+     filter_re   = models.CharField(blank=True)
+     skip_next   = models.IntegerField(help_text=
+                          "Skip the next N review assignments")
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks & Kivinen              Informational                    [Page 14]
+
+RFC 7735                     Review Tracking                January 2016
+
+
+ class ReviewResultSet(models.Model):
+     """
+     This table provides a way to point out a set of ReviewResultName
+     entries that are valid for a given team in order to be able to
+     limit the result choices that can be set for a given review as a
+     function of which team it is related to.
+     """
+     team        = models.ForeignKey(Group)
+     valid       = models.ManyToManyField(ReviewResultName)
+
+ class ReviewRequest(models.Model):
+     """
+     There should be one ReviewRequest entered for each combination of
+     document, rev, and reviewer.
+     """
+     # Fields filled in on the initial record creation:
+     time          = models.DateTimeField(auto_now_add=True)
+     type          = models.ReviewTypeName()
+     doc           = models.ForeignKey(Document,
+                            related_name='review_request_set')
+     team          = models.ForeignKey(Group)
+     deadline      = models.DateTimeField()
+     requested_rev = models.CharField(verbose_name="requested_revision",
+                             max_length=16, blank=True)
+     state         = models.ForeignKey(ReviewRequestStateName)
+     # Fields filled in as reviewer is assigned, and as the review
+     # is uploaded
+     reviewer      = models.ForeignKey(Reviewer, null=True, blank=True)
+     review        = models.OneToOneField(Document, null=True,
+                                                    blank=True)
+     reviewed_rev  = models.CharField(verbose_name="reviewed_revision",
+                                      max_length=16, blank=True)
+     result        = models.ForeignKey(ReviewResultName)
+
+
+Appendix B.  Suggested Features Deferred for Future Work
+
+   Brian Carpenter suggested a set of author/editor-focused requirements
+   that were deferred for another iteration of improvement.  These
+   include providing a way for the editors to acknowledge receipt of the
+   review, potentially tracking the email conversation between the
+   reviewer and document editor, and indicating which review topics the
+   editor believes a new revision addresses.
+
+
+
+
+
+
+
+
+Sparks & Kivinen              Informational                    [Page 15]
+
+RFC 7735                     Review Tracking                January 2016
+
+
+Acknowledgements
+
+   Tero Kivinen and Henrik Levkowetz were instrumental in forming this
+   set of requirements and in developing the initial Django models in
+   the appendix.
+
+   The following people provided reviews of this document: David Black,
+   Deborah Brungard, Brian Carpenter, Elwyn Davies, Stephen Farrell,
+   Joel Halpern, Jonathan Hardwick, Russ Housley, Barry Leiba, Jean
+   Mahoney, Randy Presuhn, Gunter Van De Velde, and Martin Vigoureux.
+
+Authors' Addresses
+
+   Robert Sparks
+   Oracle
+   7460 Warren Parkway
+   Suite 300
+   Frisco, Texas  75034
+   United States
+
+   Email: rjsparks@nostrum.com
+
+
+   Tero Kivinen
+   INSIDE Secure
+   Eerikinkatu 28
+   Helsinki  FI-00180
+   Finland
+
+   Email: kivinen@iki.fi
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks & Kivinen              Informational                    [Page 16]
+