ICANN | ICANN / IANA - IETF MoU Supplemental Agreement
  ICANN Logo

ICANN / IANA - IETF
MoU Supplemental Agreement


ICANN / IANA - IETF MoU Supplemental Agreement

Introduction

This document is concluded between the IETF Administrative Support Activity (IASA) and ICANN to supplement the Memorandum of Understanding between the IETF and ICANN concerning the technical work of the Internet Assigned Numbers Authority function of ICANN (ICANN/IANA) dated March 1, 2000.

This supplemental agreement between ICANN/IANA and the IASA, forms part of the missing criteria and procedures referred to in section 4.1 of the MoU and describes the commitments, services, and tasks ICANN/IANA undertakes on behalf of the IETF, as well as the commitments, services, and tasks members of the IETF community will provide to ICANN/IANA at the direction of the IESG and/or IAB.

This agreement describes a base level of commitment on behalf of both parties. It is anticipated that this document will evolve over time as new tasks are identified, existing tasks are completed, and service time expectations are revised. Specific details of this SLA may be modified (or clarified) at any time by mutual agreement.

Services

  1. ICANN/IANA will maintain a publicly accessible, web-based “Resource Registry Matrix” document that describes:
    1. The name of each registry;
    2. Requirements for parameters in that registry;
    3. The normative RFC defining the requirement for the registry if applicable;
    4. Expert’s name if applicable

    This Resource Registry Matrix will:

    1. Be kept current;
    2. Use hyperlinks to connect the Matrix to the registries it describes;
    3. Use “mailto:” links to supply feedback to IANA;
    4. Use nesting to indicate sub-registries.
  2. ICANN/IANA will continue to modify the format of the Matrix with the final display format being mutually agreed to by the IETF-IANA committee and ICANN/IANA.

  3. IANA will provide, on a queue-by-queue basis, mechanisms that allow for Public and IESG transparency into status of individual requests. This transparency includes the ability to:
    1. Find/verify the existence of a request;
    2. View the actual status of request and who holds the “action item”.
  4. Note that the Public and IESG/requester views may be different. The IESG/requester view may include more detail that is not appropriate for public visibility.

    The IESG transparency into the status of individual requests shall be accomplished within 6 months of agreement implementation. The Public version will be completed within 3 months following review by the committee of the IESG/requester view.

    The IANA will continue to provide the public view of the status of approved Internet Drafts (www.iana.org/draft-status/draft-queue-status-all.html) until by mutual agreement it is no longer needed.

  5. ICANN/IANA will make reasonable efforts to ensure that no single point of failure/expertise exists for its processes. Beginning with the first monthly report following implementation of this agreement, ICANN/IANA shall, in confidence to the IETF-IANA committee, document (in a separate document to the monthly report) all known single points of failure/expertise and will detail efforts undertaken to address and/or ameliorate them.
  6. ICANN/IANA will reduce the request backlog existing at the implementation of this agreement to zero for all queues within six (6) months of implementation of this Agreement.
  7. ICANN/IANA shall inventory all published RFCs that called for the creation of registries, and requests for Ports and PENS to verify that there are no uncompleted work items within six (6) months of implementation of this Agreement.
  8. ICANN/IANA will notify the resource requester WITHIN THREE (3) BUSINESS DAYS OF when ICANN/IANA has an expectation that action on the request will exceed established service levels with an explanation for the delay and a forecast as to when action will be completed on the request.
  9. ICANN/IANA will provide Fast Track Expedited Processing as an exception to its first-in, first-out policy when requested by the IESG.
  10. Service Levels

    Due to the nature of resource request reviews, ICANN/IANA and the IETF community are jointly responsible for cooperatively managing the resource request process. ICANN/IANA has control over the functions it performs directly, e.g., receiving requests, making sure they are syntactically and semantically sensible, forwarding the requests to Designated Experts where appropriate, creating and modifying the registries, etc. The IETF community has direct or indirect control over functions performed by third parties, including IESG Designated Experts, the IESG, the IAB, the RFC Editor, and the requester. As such, the processing of requests has a “gross processing time” calendar days goal established for each function and a “net processing time” calendar days goal to reflect time expended directly by ICANN/IANA.

  11. When registries using Designated Experts are created, the IESG shall assign Designated Experts for resource registries at time of document approval and notify ICANN/IANA of those assignments. ICANN/IANA may not assign resources in a registry until after the IESG has assigned Designated Experts for that resource’s registry.
  12. ICANN/IANA shall meet or exceed “net” processing time service expectations/commitments for 90% of all work requests as defined in “ Appendix A – ICANN/IANA Service Time Commitments”.
  13. “Third party processing time”, that is, the gross processing time minus the net processing time, which exceeds the goals in Appendix A (unless otherwise stated elsewhere herein) shall trigger the appropriate escalation procedure described in the section entitled “ Escalation”.
  14. ICANN/IANA shall provide due dates in assignments for third party actions, such as Designated Experts, based upon processing times specified for such action herein.
  15. It is anticipated that processing time goals may change over time and with experience.
  16. Escalation

    The following escalation processes shall be implemented within one (1) month of implementation of this agreement to ensure an orderly escalation path to handle the cases where timely responses are not forthcoming.

  17. Designated Experts Escalation:
    1. ICANN/IANA shall forward the request to the primary Designated Expert within seven (7) calendar days after receiving a correct and complete request.
    2. ICANN/IANA shall wait for a response from the Designated Expert for fourteen (14) calendar days. ICANN/IANA shall re-forward the request to the primary Designated Expert and forward the request to the secondary Designated Expert(s) (if applicable) every two (2) business days if no response is received thereafter for a period of thirty days.
    3. If ICANN/IANA does not receive a response within thirty (30) calendar days from the Designated Expert, ICANN/IANA shall notify the IESG of Designated Expert failure and request resolution of the problem (e.g., by replacing the Designated Expert per RFC 2434 and subsequent revisions).
  18. IESG Escalation:
    1. Upon issuing a request to the IESG (and document shepherds when appropriate), ICANN/IANA shall wait for a response from the IESG for fourteen (14) calendar days. ICANN/IANA shall re-forward the request to the IESG at least once per business week thereafter until the thirtieth day.
    2. If ICANN/IANA does not receive a response within thirty (30) calendar days, ICANN/IANA shall notify the IETF-IANA committee of the lack of an IESG response to a request in a timely fashion and will request instruction as to what to do with the request.
    3. ICANN/IANA shall wait for a response from the IETF-IANA committee for fourteen (14) calendar days. ICANN/IANA shall re-forward the request to the IETF/IANA committee at least once per week until the thirtieth day.
    4. If ICANN/IANA does not receive a response from the IETF/IANA committee within thirty (30) calendar days, ICANN/IANA shall notify the IAB of the lack of a response from the IESG and/or the IETF-IANA committee. The IAB is tasked with working with the IESG and other relevant parties to resolve the issue. In order to preserve the normal appeals chain (RFC 2434bis), the IAB is not expected to directly resolve the request itself.
  19. Requester Escalation:

    When ICANN/IANA is waiting on a response from the requestor, ICANN/IANA will re-forward the request regularly (e.g., once per week). If no response is received within 60 days, ICANN/IANA may send a notification of the administrative close of the request (without prejudice) to the requester and close the ticket.

  20. ICANN/IANA will publicly document an external escalation path that can provide the IESG and others with a standard path for escalating issues regarding requests, work, process, and productivity within two (2) months of implementation of this agreement.
  21. ICANN/IANA will, in confidence to the IETF-IANA committee, provide documentation of its internal escalation processes including all steps ICANN/IANA would take should a request get “stuck” in a particular state within ICANN/IANA within two (2) months of implementation of this agreement.
  22. Documentation

  23. ICANN/IANA will document the functions it performs for the IETF within three (3) months of implementation of this agreement. The processes and procedures to be documented include:
    1. Creation of new public registries as called for in IESG approved documents;
    2. Maintenance of public registries including updating registries as called for in IESG approved documents as well as updating registries via appropriate requests submitted directly to ICANN/IANA (i.e., for registries not requiring action as part of a document approval process);
    3. Review (for ICANN/IANA actions) all documents that appear on IESG telechats (not all of which undergo a formal IETF Last Call). For approved documents, see Appendix B – IANA Document Flow for a depiction of how documents are processed within ICANN/IANA;
    4. Interactions with document authors (and the IESG) when ensuring the ICANN/IANA considerations are sufficiently clear and unambiguous so that ICANN/IANA can carry out any associated actions (done prior to the document approval by the IESG);
    5. Coordination with the RFC Editor in the final steps of document publication;
    6. Maintenance of a publicly accessible list of the Designated Experts associated with those registries that make use of a Designated Expert, as well as a non-publicly accessible list of the contact information for those experts;
    7. Continue to provide regular updates, not less than once per business day, of a publicly accessible web page that provides a listing of the state of all approved Internet Draft documents in ICANN/IANA Internet-Draft queue.
  24. Reports

  25. ICANN/IANA will track and publicly report on a monthly basis within one (1) month of implementation of this agreement:
    1. Resource allocation statistics as described in item 20;
    2. The utilization of all identified finite resources defined within ICANN/IANA registries;
    3. Efforts that have addressed single points of failure/expertise (see item 3).
  26. ICANN/IANA will provide publicly accessible, clear, and accurate periodic statistics showing work that has been done and the work items that are currently queued within two (2) months of implementation of this agreement. These statistics should be drawn over all IETF-related ICANN/IANA requests broken down into meaningful categories, i.e.:
    1. IESG approved documents;
    2. Review of documents on IESG telechat agendas;
    3. New MIME type requests;
    4. Modifications to and/or deletions of MIME type requests;
    5. New Port number requests;
    6. Modifications to and/or deletions of Port number requests;
    7. New Private Enterprise Number (PEN) requests;
    8. Modifications to and/or deletions of PEN requests;
    9. Requests for the creation and/or deletion of registries;
    10. Requests relating to other IETF-created registries for which the request rate is more than five per month.

    For each of these categories information should be collected for:

    1. Number of requests in the queue at the beginning of the reporting period
    2. Number of new requests received during the reporting period
    3. Number of requests completed during the reporting period
    4. Number of requests in the queue at the end of the reporting period
    5. Histogram showing the ages of requests still in the queue at end of reporting period.

    For completed requests, information should be collected for:

    1. Average service times;
    2. Standard deviation from the average service times;
    3. Minimum service time;
    4. Median service time;
    5. Cumulative stats reflecting outliers, i.e., the totals of all completed requests within their respected categories, including outliers;
    6. Maximum service time;
    7. Histogram of cumulative stats reflecting outliers (as e. above), data by proportion.

      (1) number completed within 5 days,

      (2) number completed within 10 days,

      (3) number completed within 20 days,

      (4) number completed within 40 days,

      (5) number completed in more than 40 days

      (6) number completed within goals (7 and 14 days).

    These service times should be collected and published for gross, net and third party times.

    The exact statistics in this SLA are a starting point and are expected to change over time based upon experience. Such changes may be made by mutual agreement.

  27. ICANN/IANA will, where data available, provide statistical data as described in item 20 from January 1, 2006 that can be reconciled forward to permit trend evaluation within three (3) months of implementation of this agreement.
  28. The optimal form for displaying periodic statistics is a work in progress and will likely change over time. ICANN/IANA will provide access to the raw "event log" data from which statistics can be generated to allow others to generate statistics/reports from the underlying data within one (1) month of agreement implementation .
  29. Collaboration

  30. ICANN/IANA shall work with the appropriate parties to integrate the IANA ticketing system with other IETF tools (e.g., ID Tracker) and the RFC Editor tracker by October 1, 2007. For an example of integration, it should be possible to:
    1. "Click" from ID tracker to see actual IANA state, when applicable;
    2. Log ICANN/IANA document review comments from within the ID tracker
    3. Easily find document review comments from within ID tracker
    4. See a clear indication within ID tracker as to whether IANA has performed a review, has significant concerns, and whether they have been addressed (e.g., an IANA "discuss")
  31. Within one (1) month of agreement implementation, ICANN/IANA shall provide raw data weekly, including states and substates, to the IETF-IANA committee until the completion of the integration. See Reports.

  32. ICANN/IANA shall work with the IETF-IANA committee to review all registries for clarity:
    1. Prioritize “clarity challenged” registries (as defined by the IESG) ;
    2. Request input from existing working groups as appropriate
    3. Request input from the wider community
  33. ICANN/IANA will review and provide input for revision of RFC 2434 (see draft-narten-iana-considerations-rfc2434bis-03.txt) within one (1) month of implementation of this agreement. ICANN/IANA will provide clarification for the “how to” sections by creating sample implementations of different types of registries. The IESG will work with authors to enhance conformance to RFC 2434[bis].
  34. ICANN/IANA and IESG will examine the use of mechanisms defined in RFC 3553 to refer precisely to the registry name spaces by URN.
  35. ICANN/IANA will provide a teleconference bridge to facilitate monthly teleconferences between ICANN/IANA and the IETF-IANA committee. The date, time, and duration of these calls will be mutually agreed between ICANN/IANA and the IETF-IANA committee members. At a minimum, IANA will, as part of these monthly teleconferences, provide a status update of all outstanding issues raised at the previous month’s teleconference.
  36. The Parties agree to review the terms of this document in one year to determine whether any modifications may be required. Prior to this review, this document will be interpreted flexibly.
  37. IANA Action Summary Table

    IANA Action Summary

     

    Action

    Reference

    Delivery Date After Effective Date

    1

    IESG transparency into status of individual requests

    2

    Within 6 months

    2

    Public transparency into status of individual requests

    2

    Within 3 months of committee review

    3

    Single points of failure documentation to IETF-IANA WG

    3

    Beginning with first monthly report

    4

    Reduce monthly backlog to zero for each queue

    4

    Within 6 months

    5

    Inventory all RFCs calling for registry creation to verify completion

    5

    Within 6 months

    6

    Escalation processes shall be implemented

    Escalation

    Within 1 month

    7

    Publicly document external escalation path

    16

    Within 2 months

    8

    Document internal escalation process to IETF-IANA WG

    17

    Within 2 months

    9

    Document functions performed for IETF

    18

    Within 3 months

    10

    Track and publicly report on a monthly basis

    19

    Within 1 month

    11

    Provide publicly accessible, clear and accurate periodic statistics

    20

    Within 2 months

    12

    Provide statistical data in Section 19 from Jan 1 2006 forward

    21

    Within 3 months

    13

    Provide access to raw "event log" data

    22

    Within 1 month

    14

    Work to integrate IANA ticketing system with IETF and RFC Editor tracking systems

    23

    By October 1, 2007

    15

    Provide raw data weekly to IETF-IANA WG

    23

    Within 1 month and until tracker integration

    16

    Provide input to RFC 2434 revision

    25

    Within 1 month

    17

    Review terms of agreement

    28

    In 1 year

    18

    90% of requests shall be processed within processing goals

    Notes

    Within 6 months

  38. Effective Date

  39. This agreement is effective January 1, 2007.

    Agreed to on ____/___/____ by

    (Month) (Day) (Year)

    On behalf of ICANN:

    On behalf of IASA:

    ___________________________________

    ___________________________________

    Signature

    Signature

    Paul Twomey

    Ray Pelletier

    Name

    Name

    President/CEO

    IETF Administrative Director

    Title

    Title

    ICANN

    IASA

    Organization

    Organization

Appendix A – ICANN/IANA Service Time Commitments

Resource

Proc Time Now

Proc Time in 6 Mo

Clock starts at

Clock stops at

Documents (including IETF and RFC Editor submissions)

20

14

Receipt of official IESG approval of the document or receipt of official notice of intend to publish from the RFC-Editor.

Sending an "IANA Actions Complete" message to the RFC Editor

Protocol parameter requests requiring IESG Designated expert and/or IETF mailing list review

15

14

Receipt of initial request

Notification of resource assignment

Protocol parameter requests that do not require technical review

10

7

Receipt of initial request

Notification of resource assignment

All other requests

20

14

Receipt of initial request

Notification of resource assignment

Additional ICANN/IANA and Third Party Service Time Requirements:

A. ICANN/IANA shall update the Resource Registry Matrix with the IESG Designated Experts within 1 week of notification of the appointment.

B. The processing time goals for third parties shall be in calendar days as follows:

  1. Designated Experts – 14 days
  2. Requester – 30 days
  3. IESG – 14 days
  4. Other – 7 days

Notes:

  • At implementation, ICANN/IANA commits to continuous process improvement leading to the reduction of outliers as reflected on histograms, and of processing times less than or equal to the values in the column entitled “Processing Time Now”. Within six (6) months of implementation of this agreement, ICANN/IANA commits to processing times less than or equal to the values in the column entitled “Processing Time within 6 Months” for 90% of the requests.
  • All processing times (“Proc Time”) are given in “net” ICANN/IANA time in terms of “calendar days”.
  • ICANN/IANA will notify the committee in advance if it anticipates that any of these service time commitments will not be met. In such a case, ICANN/IANA will provide documentation on the cause(s) of being unable to meet the commitment(s) and steps taken to address those causes.
  • Changes to the service time commitments will be mutually agreed between ICANN/IANA and the IETF-IANA committee.

Appendix B – IANA Document Flow

Appendix B - IANA Document Flow


Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.

Page Updated 02-Feb-2012
©2002  The Internet Corporation for Assigned Names and Numbers. All rights reserved.