doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc6359.txt b/doc/rfc/rfc6359.txt
new file mode 100644
index 0000000..380e180
--- /dev/null
+++ b/doc/rfc/rfc6359.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         S. Ginoza
+Request for Comments: 6359                                           AMS
+Category: Informational                                        M. Cotton
+ISSN: 2070-1721                                                    ICANN
+                                                               A. Morris
+                                                                     AMS
+                                                          September 2011
+
+
+                       Datatracker Extensions to
+           Include IANA and RFC Editor Processing Information
+
+Abstract
+
+   This document captures the requirements for integrating IANA and RFC
+   Editor state information into the Datatracker to provide the
+   community with a unified tool to track the status of their document
+   as it progresses from Internet-Draft (I-D) version -00 to RFC.
+   Extending the Datatracker to hold document data from I-D version -00
+   to RFC allows for increased automation between the Datatracker, IANA,
+   and RFC Editor, thus reducing manual labor, processing errors, and
+   potential delay.  Therefore, this document also describes the
+   requirements to make such automation possible.
+
+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/rfc6359.
+
+
+
+
+
+
+
+
+
+
+
+
+Ginoza, et al.                Informational                     [Page 1]
+
+RFC 6359                More Datatracker Updates          September 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 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.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+1.  Introduction
+
+   The IETF Datatracker is a web-based system for managing information
+   about Internet-Drafts (I-Ds) and RFCs, IPR disclosures, liaison
+   statements, and several other important aspects of the document
+   process [IDTRACKER].  In this document, the term "IETF Datatracker"
+   is used as a generic name for the existing tool used to track state
+   changes as Internet-Drafts are processed.  The word "IETF" in the
+   name "IETF Datatracker" is not meant to limit use of the tool to the
+   IETF document stream; this document expands use of the tool to the
+   other streams described in [RFC4844].
+
+   The Datatracker is used to report on the status of I-Ds that have
+   been submitted to the IESG for evaluation and publication.  The
+   Datatracker will be extended, according to the requirements defined
+   in [RFC6174] and [RFC6322], to include tracking information about a
+   document during its progression from version -00 to it being
+   requested for IESG evaluation.  However, the Datatracker, ICANN
+   (performing the IANA function), and RFC Editor operate on separate
+   systems with varying degrees of visibility into the processing that
+   takes place once the stream managers have approved a document for
+
+
+
+Ginoza, et al.                Informational                     [Page 2]
+
+RFC 6359                More Datatracker Updates          September 2011
+
+
+   publication as an RFC.  This document defines the requirements for
+   extending the Datatracker to include increased IANA and RFC Editor
+   state information, so that the Datatracker covers the lifetime of an
+   I-D from version -00 to RFC publication.
+
+   Additionally, this document lists the processes between the IANA, RFC
+   Editor, and Secretariat (via the Datatracker) that should be
+   automated for accuracy and timely processing.  While this document
+   includes some details of the IANA, RFC Editor, and Secretariat
+   process, this document does not define any of the processes.  The
+   processes are continually reviewed for process optimization and need
+   to remain flexible to adapt to new changes in policy and environment.
+   Processes are defined and set by each of the entities respectively.
+
+   The IANA and RFC Editor are functions independent of the IETF.  When
+   an Internet-Draft enters the IANA queue, IANA retains ownership of
+   its own data, state names, and tracking systems.  Similarly, when an
+   Internet-Draft enters the RFC Editor's queue, the RFC Editor retains
+   ownership of its own data, state names, and tracking systems.  This
+   document discusses how the data from the IANA and RFC Editor queues
+   can be better reflected in the Datatracker to help inform the IETF
+   community what the state of a document is throughout its lifetime.
+
+   Prior to when an Internet-Draft is approved for publication as an
+   RFC, the Datatracker is the definitive source for tracking IANA
+   status information, and the IANA data is editable (by IANA and the
+   Secretariat) in the Datatracker.  After an Internet-Draft is approved
+   for publication as an RFC, the IANA tracking system becomes the
+   definitive source for tracking IANA status information, and the data
+   can no longer be edited in the Datatracker.  At that point, the data
+   in the Datatracker is only a reflection of the data in the IANA
+   tracking system.  If there is a discrepancy between the two after
+   this point, the data in the IANA tracking system is assumed to be
+   correct.
+
+   The RFC Editor's tracking system is always the definitive source for
+   tracking the RFC Editor status of a document.  RFC Editor data is not
+   editable via the Datatracker.  The information in the Datatracker is
+   always a reflection of the information in the RFC Editor's tracking
+   system.
+
+2.  Integration of Data between the IANA and Datatracker
+
+2.1.  IANA Information to Be Added to the Datatracker
+
+   Currently, IANA reviews and touches IETF stream documents at 4
+   different stages in the process from I-D to RFC: IETF Last Call, IESG
+   Review, Document Approval (for publication), and RFC Publication.
+
+
+
+Ginoza, et al.                Informational                     [Page 3]
+
+RFC 6359                More Datatracker Updates          September 2011
+
+
+   Most of these state changes and issues are not captured in the
+   Datatracker.  For the IRTF (Internet Research Task Force) and
+   Independent streams, the IANA review process begins when IESG Review
+   is requested.  For the IAB (Internet Architecture Board) stream,
+   review would begin upon request for publication as an RFC.
+
+   This section specifies the requirements for including additional IANA
+   information in the Datatracker.
+
+   -  IETF Last Call Comments
+
+      Currently, IANA reviews I-Ds that have been sent to IETF Last
+      Call, inputs comments in their data system, and then emails their
+      comments to authors, WG chairs, and then to the IESG.  These
+      comments are also manually entered into the Datatracker for the
+      public record.  However, it is difficult to determine whether the
+      IANA issues have been resolved.  To help facilitate tracking of
+      IANA issues, a display is needed to show 5 new IANA substates, in
+      a similar fashion to how RFC Editor State is currently shown in
+      the Datatracker (see the example, later in this section, of how
+      IANA state information could appear in the Datatracker for
+      draft-example-00).
+
+      1) IANA Review Needed
+
+         This substate will allow the community, Secretariat, and IANA
+         to easily track which documents have or have not been reviewed
+         by IANA.  If this substate is NOT set to "IANA Not OK", "IANA
+         OK -- Actions Needed", or "IANA OK -- No Actions Needed", the
+         substate should be set to "IANA Review Needed" by default (this
+         is the first substate for tracking IANA data).  For documents
+         that originate from a non-IETF stream, the default will be
+         used.
+
+      2) IANA OK -- Actions Needed
+
+         This substate covers documents that require IANA actions, and
+         the IANA Considerations section indicates the details of the
+         actions correctly.
+
+      3) IANA OK -- No Actions Needed
+
+         This substate covers documents that require no IANA actions,
+         and the IANA Considerations section indicates this correctly.
+
+
+
+
+
+
+
+Ginoza, et al.                Informational                     [Page 4]
+
+RFC 6359                More Datatracker Updates          September 2011
+
+
+      Note: The substate will be set to "IANA OK -- Action Needed" or
+      "IANA OK -- No Actions Needed" (from "IANA Not OK") once any
+      outstanding issues have been resolved.  The comments section will
+      be used to provide details in the History log about whether there
+      are no IANA actions, the text is OK, or the issues have been
+      resolved.
+
+      4) IANA Not OK
+
+         If IANA has issues with the text of the IANA Considerations
+         section of a document, the substate should be set to "IANA Not
+         OK", and the comment field should be populated with a
+         description of the issues and questions.  In addition to any
+         questions IANA may have, IANA will also include in the comments
+         field whether expert review is required, if the document is
+         dependent on another document (e.g., document B registers
+         values in a registry created by document A, which hasn't been
+         published yet), and if there is a registry expert appointment
+         required.
+
+      5) Version Changed -- Review Needed
+
+         This substate will allow the community, Secretariat, and IANA
+         to easily track which documents have been reviewed and
+         subsequently when a version of an Internet-Draft in Last Call
+         has changed, therefore requiring a second review of the
+         document by IANA to ensure that either the IANA considerations
+         have not changed, or any changes made to the document affecting
+         IANA actions are clear.  This substate applies to I-Ds that are
+         in any substate except "IANA Review Needed" and "Version
+         Changed -- Review Needed".
+
+         When new versions are available, the Datatracker will
+         automatically set the IANA substate to "Version Changed --
+         Review Needed".
+
+   Information providing the status of the IANA review (one of the 5
+   substates listed above) should be included as part of the evaluation
+   message (sent to the IESG) so that IANA can determine if, and what,
+   further action is required.
+
+   All comments will be recorded in the History log.  However, to reduce
+   redundancy and manual effort, the Datatracker should provide the
+   ability to receive state information and related comments from the
+   IANA tracking system.  There should be a notification that comments
+   have been entered in the IANA-maintained system, and entry of those
+   comments into the Datatracker and distribution of those comments to
+   the authors should be automated.
+
+
+
+Ginoza, et al.                Informational                     [Page 5]
+
+RFC 6359                More Datatracker Updates          September 2011
+
+
+   - IESG Evaluation
+
+      As not all documents receive an IETF Last Call, this state is
+      sometimes the first time that IANA reviews a document.  For a
+      document that wasn't IETF Last Called, IANA reviews the document,
+      enters comments in their own tracking system, distributes email to
+      authors and other interested parties (e.g., WG chairs, ISE
+      (Independent Submissions Editor)), and then enters those same
+      comments into the Datatracker, where they are recorded in the
+      History log.  In cases where a document was IETF Last Called, IANA
+      checks for and reviews version changes and re-reviews documents to
+      ensure that any identified IANA issues have been resolved.
+
+      Comments will continue to be recorded in the History log.
+      However, to reduce redundancy and manual effort, the Datatracker
+      should provide the ability for IANA to enter substate information
+      and related comments into the IANA tracking system, and
+      distribution of those comments to the authors and entry into the
+      Datatracker should be automated.
+
+      Ideally, the authors will have responded to and resolved any IANA
+      issues prior to the document being slated for an IESG telechat.
+      However, if any document continues to have an "IANA Not OK",
+      "Version Changed -- Review Needed", or "IANA Review Needed"
+      substate and is slated for the IESG telechat, it should be called
+      out in the Agenda Package.  For example, it could appear as
+      follows:
+
+       o draft-example-00
+         Title of Internet-Draft
+         Note: John Doe (jdoe@example.com) is the document shepherd.
+         Token: Jane Doe
+         IANA: IANA Not OK
+
+      This will ensure that IANA and the Area Directors (ADs) are aware
+      that there are still IANA issues to be addressed prior to
+      publication, or that initial or follow-up IANA review is required
+      and not yet completed (in cases where the substate is listed as
+      "IANA Review Needed" or "Version Changed -- Review Needed").
+
+
+
+
+
+
+
+
+
+
+
+
+Ginoza, et al.                Informational                     [Page 6]
+
+RFC 6359                More Datatracker Updates          September 2011
+
+
+   -  Document Approved for Publication
+
+      Once a document has been approved for publication, the document
+      enters the IANA queue and is tracked using IANA-defined states.
+      This state information is not currently available via the
+      Datatracker.  In order for the community to view the IANA
+      processing states without being redirected to the IANA queue, the
+      Datatracker should be extended to include IANA state information
+      as defined by IANA.  For example, IANA state information could
+      appear in the metadata portion of the document as follows:
+
+      Document type:          Active Internet-Draft (FOO WG document)
+      Last updated:           2010-09-20
+      State:                  RFC Ed Queue
+      RFC Editor State:       EDIT IANA
+      IANA State:             In Progress
+      Intended status:        Proposed Standard
+
+      IANA state-change information will link to the IANA queue, and
+      will be captured as a line item in the History log.  IANA will
+      notify the Datatracker when changes are made in the IANA queue.
+
+      Once the IANA actions have been completed, the Datatracker History
+      log will be updated to include the actions completed by IANA
+      (i.e., the author-approved actions).  This information will
+      include the same information that is sent to the RFC Editor upon
+      completion of IANA actions.
+
+      The IANA State field may be any of the states defined by IANA.
+      The list of IANA state names in use at the time this document was
+      published is provided in Appendix A; however, IANA states are
+      defined by IANA and are subject to change.  If there are any
+      discrepancies between the state names listed in this document and
+      those listed on the IANA queue page
+      (http://www.iana.org/about/performance/ietf-draft-status/), the
+      IANA queue is definitive.  States may be added or removed by IANA;
+      IANA will work with the IETF Administrative Oversight Committee
+      (IAOC) to update the Datatracker as necessary.
+
+   -  RFC Publication
+
+      References to the I-D are updated to refer to the RFC once it is
+      published, and minor updates may be made to match the published
+      RFC.  This data will be tracked in the Datatracker to show when
+      the references in the IANA registries were updated to include the
+      newly assigned RFC number.
+
+
+
+
+
+Ginoza, et al.                Informational                     [Page 7]
+
+RFC 6359                More Datatracker Updates          September 2011
+
+
+2.2.  Future IANA Information to Be Available via the Datatracker
+
+   The document "Definition of IETF Working Group Document States"
+   [RFC6174] includes the following:
+
+      4.3.1.  Awaiting Expert Review/Resolution of Issues Raised
+
+         This tag means that someone (e.g., an author or editor of the
+         WG draft, or a WG Chair) has initiated an expert review of the
+         document and the review has not yet been completed and/or the
+         resolution of issues raised by the review has not yet been
+         completed.  Examples of expert reviews include cross-area
+         reviews, MIB Doctor reviews, security expert reviews, and IANA
+         reviews.
+
+         WG drafts tagged with this annotation should retain the tag
+         until the review is complete and possibly until any issues
+         raised in the review are addressed.
+
+   IANA is in the process of documenting how an expert review is
+   conducted during the lifetime of an Internet-Draft.  Once the process
+   has been defined, the Datatracker should be updated to indicate if a
+   document requires "Expert Review" [RFC5226] (either for the entire
+   document or a portion thereof); if the expert reviewer has issues
+   with what they are being requested to review; and, if applicable,
+   whether the expert reviewer has approved or rejected the requested
+   registration(s).  There may be a need to complete expert reviews
+   again before publication of a document if there have been changes to
+   the text relevant to the review by the expert.  In cases where a new
+   registry is being created in the document, an indicator of whether an
+   expert needs to be appointed by the IESG would also be useful.
+
+2.3.  Permissions to Change IANA State Information
+
+   IANA state changes should be automated, but IANA should have the
+   ability to log in to the Datatracker to manually update the system as
+   well.
+
+   The IETF Secretariat should also have the ability to change the IANA
+   state if necessary.
+
+   It is expected that this feature would only be used to correct
+   issues; it is not intended to be part of regular operations.
+
+
+
+
+
+
+
+
+Ginoza, et al.                Informational                     [Page 8]
+
+RFC 6359                More Datatracker Updates          September 2011
+
+
+3.  Integration of Data between the RFC Editor and Datatracker
+
+   For quite some time, the RFC Editor was seen as a black box, where
+   documents were submitted for publication, went through some process,
+   and came out as RFCs.  Over time, the community asked for a more
+   transparent process; thus, state information was made available on
+   the RFC Editor website.  Currently, some of that state information is
+   available from the Datatracker.  However, for additional transparency
+   about the RFC Editor process, the Datatracker should be extended to
+   hold supplementary RFC Editor state and process (e.g., MISSREF)
+   information.  This section defines the requirements for RFC Editor
+   state information to be added to the Datatracker to provide more
+   transparency and allow for a unified end-to-end tracking system.
+
+3.1.  RFC Editor Information to Be Added to the Datatracker
+
+   Once a document has been approved for publication, the document
+   enters the RFC Editor queue and is tracked using RFC-Editor-defined
+   states.  Some RFC Editor state information is currently available via
+   the Datatracker, but the information is not stored in the History
+   log.  RFC-Editor-defined state information will continue to be shown
+   as is done currently.  In addition, a line item will be entered into
+   the History log each time a document changes state.  The RFC Editor
+   shall continue to provide a queue file to allow data extraction; in
+   addition, there will be a machine-readable notification to the
+   Datatracker when state changes are made.
+
+   RFC Editor state information should continue to appear in the
+   metadata portion of the document available using the Datatracker.
+   For example, an entry might appear as follows (including the IANA
+   State information):
+
+      Document type:          Active Internet-Draft (TLS WG document)
+      Last updated:           2010-09-20
+      State:                  RFC Ed Queue
+      RFC Editor State:       EDIT IANA
+      IANA State:             In Progress
+      Intended status:        Proposed Standard
+
+   The RFC Editor State field may be any of the states defined by the
+   RFC Editor.  The list of RFC Editor state names in use at the time
+   this document was published is provided in Appendix B, but RFC Editor
+   states are defined by the RFC Editor and are subject to change.  If
+   there are any discrepancies between the state names listed in this
+
+
+
+
+
+
+
+Ginoza, et al.                Informational                     [Page 9]
+
+RFC 6359                More Datatracker Updates          September 2011
+
+
+   document and those listed on the RFC Editor queue page
+   (http://www.rfc-editor.org/queue2.html), the RFC Editor queue is
+   definitive.  States may be added or removed by the RFC Editor; the
+   RFC Editor will work with the IAOC to update the Datatracker as
+   necessary.
+
+   Although RFC Editor state information is already available in the
+   Datatracker, the Datatracker should be updated to include some
+   additional data that may help individuals understand the status of
+   their document.  In particular, the Datatracker should be updated to
+   include the following data:
+
+   1) links to AUTH48 pages
+
+      AUTH48 pages provide information about which authors have approved
+      the document for publication, whether AD approval is required, and
+      sometimes a summary of issues that need to be resolved before the
+      document can move forward.
+
+   2) links to the cluster pages
+
+      Clusters are defined as documents with normative reference
+      dependencies, and documents that have been requested for
+      simultaneous publication.  (For more information, see
+      http://www.rfc-editor.org/cluster_def.html.)   The cluster pages
+      provide a view of the entire set of state information for
+      clustered documents.
+
+      Note: The RFC Editor has been working with the cluster data to
+      provide the community with accurate state information at the
+      appropriate level of detail.  The RFC Editor database may require
+      significant updates before this data can be integrated with the
+      Datatracker.
+
+   3) RFC metadata upon publication
+
+      The RFC Editor will notify the Datatracker when a new RFC has been
+      published, and the Datatracker should have the ability to
+      automatically update the relevant fields with data related to the
+      published RFC.  In particular, the RFC number will be recorded in
+      the Datatracker.  However, note that all fields are subject to
+      change during editing and should be updated; for example, the
+      document title and the list of authors are sometimes changed, and
+      character counts and page counts are always changed.
+
+
+
+
+
+
+
+Ginoza, et al.                Informational                    [Page 10]
+
+RFC 6359                More Datatracker Updates          September 2011
+
+
+   4) notation when documents are withdrawn from the RFC Editor queue
+
+      If a document is to be removed from the RFC Editor / IANA queues,
+      the responsible party (e.g., AD or Secretariat) should change the
+      state of the document in the Datatracker to something other than
+      "RFC Ed Queue".  The Datatracker should provide a text box to
+      allow the responsible party to record details about the state
+      change.  The state change and the related details will be recorded
+      in the History log.  The state change in the Datatracker will
+      trigger an email message to the RFC Editor and IANA as
+      notification that the state of the document has been set to the
+      newly assigned state, with the details provided in the text box.
+      The RFC Editor and IANA will update their queues accordingly, and
+      the document will disappear from their respective queues.
+
+4.  Other Updates to the Datatracker
+
+   While the primary goal of this document is to update the Datatracker
+   to display the IANA and RFC Editor process state information, the
+   Datatracker could hold additional data for use by IANA and the RFC
+   Editor that would allow for increased automation, thus reducing the
+   potential for delays and processing errors.  This section defines
+   requirements for updates to the Datatracker to eliminate some of the
+   administrative tasks currently performed by staff.
+
+4.1.  Datatracker to IANA
+
+   When a document is approved for publication, data will be provided in
+   a machine-readable format and will include (in addition to the usual
+   Document/Protocol Action emails) the data requested by the RFC Editor
+   in Section 4.2.
+
+4.2.  Datatracker to RFC Editor
+
+   When a document is approved for publication, data will be provided in
+   a machine-readable format and will include the following (in addition
+   to the usual Document/Protocol Action emails):
+
+      -  I-D String
+
+      -  Document Title
+
+      -  Author List
+
+      -  Author Email Addresses
+
+      -  Author Organizations (if available)
+
+
+
+
+Ginoza, et al.                Informational                    [Page 11]
+
+RFC 6359                More Datatracker Updates          September 2011
+
+
+      -  Expedited Goal Date (if applicable)
+
+         Note: This field needs to be editable for post-approval
+         changes.
+
+      -  Publication Status (as defined in [RFC2026])
+
+      -  Consensus (yes/no)
+
+      -  Source (Working Group or Research Group name, Individual,
+         or alternate-stream name)
+
+         Note: The RFC Editor database may require updates before
+         Research Group data can be received from the Datatracker.
+
+      -  IESG Contact
+
+      -  Document Shepherd <email>
+
+         Note: This is the individual currently listed in the
+         "Personnel" section of a Document/Protocol Action.
+
+      -  IANA Actions Required
+
+   Most of these items are already stored in the Datatracker.  However,
+   the following fields need to be added:
+
+      -  Expedited Goal Date
+
+      -  Consensus (yes/no)
+
+      -  Document Shepherd <email>
+
+      -  IANA Actions Required
+
+   "Consensus" is as used in [RFC5741]; it determines the appropriate
+   Status of This Memo text to be applied to IETF and IRTF documents.
+   The Consensus field should be set by the responsible individuals, and
+   it should be listed in the Agenda Package provided before an IESG
+   telechat so that the Area Directors can quickly review the status of
+   the documents under review and correct the field if Consensus was not
+   received.
+
+   Additionally, the Agenda Package provided before an IESG telechat
+   should show the expiration date of the IETF Last Call.  This will be
+   helpful for the ADs and the Secretariat to track the IETF Last Call
+   timeline.
+
+
+
+
+Ginoza, et al.                Informational                    [Page 12]
+
+RFC 6359                More Datatracker Updates          September 2011
+
+
+   When a document has been added to the RFC Editor queue (i.e., shows
+   an RFC Editor state in the Datatracker), an automated note should be
+   sent to the Secretariat as acknowledgment that the announcement has
+   been received.
+
+4.2.1.  Notifications
+
+   The Datatracker should notify the RFC Editor and the Sponsoring AD
+   when a version of an I-D has been made available after the document
+   has been approved for publication.
+
+   Additionally, the Datatracker should notify the RFC Editor and IANA
+   when the state of an I-D has been moved to something other than "RFC
+   Ed Queue" or "RFC Published" -- that is, when it should be removed
+   from the RFC Editor and IANA processing queues.  See item 4) in
+   Section 3.1 for more details.
+
+4.2.2.  Datatracker Extensions for Alternate Streams
+
+   Once the Datatracker has been updated for the alternate streams
+   [RFC6322], the Datatracker should be updated so that the following
+   are automated:
+
+   -  The Datatracker should not expire any I-Ds that are under review
+      for publication.
+
+   -  The Datatracker should automatically notify the approving body
+      when an I-D that is under review has been updated (i.e., a new
+      version has been made available).
+
+   -  The Datatracker should be updated so that the Agenda package lists
+      I-Ds according to the stream that requested publication.  This
+      should help provide additional clarity during IESG Reviews, as
+      there will be a clear indication of from which stream a document
+      originates.
+
+4.2.2.1.  Publication Requests
+
+   RFC 6322 [RFC6322] lists the requirements for extending the
+   Datatracker to account for alternate-stream states and annotations.
+   In particular, the document introduces the "Sent to the RFC Editor"
+   state, which means the document is complete and has been sent to the
+   RFC Editor for publication.
+
+   The Datatracker will provide a means for the alternate streams to
+   generate a uniform publication request.  Using the Datatracker, the
+   stream managers should be able to generate a publication request that
+   contains the relevant information for any approved I-D.
+
+
+
+Ginoza, et al.                Informational                    [Page 13]
+
+RFC 6359                More Datatracker Updates          September 2011
+
+
+   Additionally, the Datatracker will provide the data (the same data
+   provided for any IETF publication request -- see Section 4.2) in a
+   machine-readable format.  This data will be available to the IANA and
+   RFC Editor, so that data entry into the IANA and RFC Editor systems
+   can be automated.
+
+   This update will allow the IANA and RFC Editor to handle documents in
+   a similar manner, regardless of the document's stream.
+
+4.3.  Reporting Requirements
+
+   The Datatracker should have a "Show Discrepancies" feature.  It
+   should show all records in the Datatracker that fit certain criteria
+   (that seem to be a discrepancy).  In addition to showing data on
+   screen, it should send an email to defined interested parties at
+   regular intervals (e.g., weekly).  This feature will only be
+   available to a subset of individuals (namely, IANA, RFC Editor, and
+   the Secretariat), to ensure that their queues are in sync.  This will
+   be especially helpful as the Datatracker is extended (now and in the
+   future), to ensure that all parties are receiving the correct
+   messages/data.
+
+   An initial set of discrepancies should be defined, and additional
+   discrepancies could be defined over time.  For example, the initial
+   set of discrepancies could include the following:
+
+   -  Show drafts that have passed through the state "Approved
+      Announcement sent" but do not have an RFC Editor state.
+
+   -  Show drafts that have IANA state "In Progress", but RFC Editor
+      State is not equal to "IANA" or does not contain "*A" (see
+      Appendix B).
+
+   -  Show drafts that have IANA state "Waiting on RFC Editor" or
+      "RFC-Ed-Ack", but RFC Editor State is "IANA" or contains "*A"
+      (see Appendix B).
+
+   -  Show drafts that have a state of something other than "RFC Ed
+      Queue" or "RFC Published" that are listed in the RFC Editor or
+      IANA queues.
+
+5.  Security Considerations
+
+   This document does not propose any new Internet mechanisms, and has
+   no security implications for the Internet.
+
+
+
+
+
+
+Ginoza, et al.                Informational                    [Page 14]
+
+RFC 6359                More Datatracker Updates          September 2011
+
+
+Appendix A.  Current IANA States and Definitions
+
+   The currently defined IANA states are listed below.
+
+      * No value (blank) - A new document has been received by IANA, but
+        no actions have been taken
+
+      * In Progress - IANA is currently processing the actions for this
+        document
+
+      * Waiting on Authors - IANA is waiting on the document's authors
+        to respond
+
+      * Waiting on ADs - IANA is waiting on the IETF Area Directors to
+        respond
+
+      * Waiting on WGC - IANA is waiting on the IETF Working Group
+        Chairs to respond
+
+      * Waiting on RFC Editor - IANA has notified the RFC Editor that
+        the actions have been completed
+
+      * RFC-Ed-Ack - Request completed.  The RFC Editor has acknowledged
+        receipt of IANA's message that the actions have been completed
+
+      * On Hold - IANA has suspended work on the document
+
+      * No IC - Request completed.  There were no IANA actions for this
+        document
+
+   IANA states are defined by IANA and are subject to change.  If there
+   are any discrepancies between the state names listed in this document
+   and those listed on the IANA queue page
+   (http://www.iana.org/about/performance/ietf-draft-status/), the IANA
+   queue is definitive.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ginoza, et al.                Informational                    [Page 15]
+
+RFC 6359                More Datatracker Updates          September 2011
+
+
+Appendix B.  Current RFC Editor States and Definitions
+
+   The currently defined RFC Editor Queue states are listed below.
+
+      * AUTH = Awaiting Author Action
+
+      * AUTH48 = Awaiting final author approval
+
+      * EDIT = Approved by the stream manager (e.g., IESG, IAB, IRSG,
+        ISE), awaiting processing and publishing
+
+      * IANA = RFC-Editor/IANA Registration Coordination
+
+      * IESG = Holding for IESG Action
+
+      * ISR = Independent Submission Review by the ISE
+
+      * ISR-AUTH = Independent Submission awaiting author update, or in
+        discussion between author and ISE
+
+      * REF = Holding for normative reference (followed by I-D string of
+        referenced document)
+
+      * RFC-EDITOR = Awaiting final rfc-editor review before AUTH48
+
+      * TO = Time-out period during which the IESG reviews document for
+        conflict/concurrence with other IETF working group work
+        (followed by date)
+
+      * MISSREF = Awaiting missing normative reference
+
+   RFC Editor states are defined by the RFC Editor and are subject to
+   change.  If there are any discrepancies between the state names
+   listed in this document and those listed on the RFC Editor queue page
+   (http://www.rfc-editor.org/queue2.html), the RFC Editor queue is
+   definitive.
+
+   Currently, there are also a couple of state annotations used in RFC
+   Editor state-change emails.  These do not alter the Datatracker in
+   any way, but are listed here for completeness:
+
+      *A = indicates that IANA actions are required
+      *R = indicates potential REFerence holds
+
+
+
+
+
+
+
+
+Ginoza, et al.                Informational                    [Page 16]
+
+RFC 6359                More Datatracker Updates          September 2011
+
+
+Normative References
+
+   [IDTRACKER] "The IETF Datatracker tool", Web Application:
+               https://datatracker.ietf.org/, August 26, 2011.
+
+   [RFC2026]   Bradner, S., "The Internet Standards Process --
+               Revision 3", BCP 9, RFC 2026, October 1996.
+
+   [RFC4844]   Daigle, L., Ed., and Internet Architecture Board, "The
+               RFC Series and RFC Editor", RFC 4844, July 2007.
+
+   [RFC5226]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
+               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+               May 2008.
+
+   [RFC5741]   Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams,
+               Headers, and Boilerplates", RFC 5741, December 2009.
+
+   [RFC6174]   Juskevicius, E., "Definition of IETF Working Group
+               Document States", RFC 6174, March 2011.
+
+   [RFC6322]   Hoffman, P., "Datatracker States and Annotations for the
+               IAB, IRTF, and Independent Submission Streams", RFC 6322,
+               July 2011.
+
+Acknowledgments
+
+   The authors would like to thank the following individuals for their
+   input:
+
+   Amanda Baber
+   Glen Barney
+   Adrian Farrel
+   Alice Hagens
+   Paul Hoffman
+   Russ Housley
+   Ed Juskevicius
+   Henrik Levkowetz
+   Cindy Morgan
+   Ray Pelletier
+   Peter Saint-Andre
+   Robert Sparks
+   Amy Vezza
+
+
+
+
+
+
+
+
+Ginoza, et al.                Informational                    [Page 17]
+
+RFC 6359                More Datatracker Updates          September 2011
+
+
+Authors' Addresses
+
+   Sandy Ginoza
+   Association Management Solutions
+   48377 Fremont Blvd., Suite 117
+   Fremont, CA 94538
+   United States
+
+   Phone: +1 (510) 492-4000
+   EMail: sginoza@amsl.com
+   URI: http://www.amsl.com/
+
+
+   Michelle Cotton
+   Internet Corporation for Assigned Names and Numbers
+   4676 Admiralty Way, Suite 330
+   Marina del Rey, CA 90292
+   United States
+
+   Phone: +310-823-9358
+   EMail: michelle.cotton@icann.org
+   URI:   http://www.iana.org/
+
+
+   Alexa Morris
+   Association Management Solutions
+   48377 Fremont Blvd., Suite 117
+   Fremont, CA 94538
+   United States
+
+   Phone: +1 (510) 492-4000
+   EMail: amorris@amsl.com
+   URI: http://www.amsl.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ginoza, et al.                Informational                    [Page 18]
+