GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6359

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.
  1. 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

  1. 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

  1. 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.
  1. 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):
  1. I-D String
  1. Document Title
  1. Author List
  1. Author Email Addresses
  1. Author Organizations (if available)

Ginoza, et al. Informational [Page 11] RFC 6359 More Datatracker Updates September 2011

  1. Expedited Goal Date (if applicable)
       Note: This field needs to be editable for post-approval
       changes.
  1. Publication Status (as defined in [RFC2026])
  1. Consensus (yes/no)
  1. 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.
  1. IESG Contact
  1. Document Shepherd <email>
       Note: This is the individual currently listed in the
       "Personnel" section of a Document/Protocol Action.
  1. IANA Actions Required
 Most of these items are already stored in the Datatracker.  However,
 the following fields need to be added:
  1. Expedited Goal Date
  1. Consensus (yes/no)
  1. Document Shepherd <email>
  1. 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:
  1. The Datatracker should not expire any I-Ds that are under review

for publication.

  1. 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).
  1. 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:
  1. Show drafts that have passed through the state "Approved

Announcement sent" but do not have an RFC Editor state.

  1. 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).
  1. 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).
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6359.txt · Last modified: 2011/09/07 21:18 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki