RFC 7979
Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries
Pages: 37
Informational
Informational
Part 2 of 2 – Pages 20 to 37
7. References
7.1. Normative References
[BCP9info] "Information on "The Internet Standards Process -- Revision 3"", <http://www.rfc-editor.org/info/rfc2026>. [METRICS] IANA, "Performance Standards Metrics Report", <http://www.iana.org/performance/metrics>.
[MOUSUP] IAOC, "Supplements to RFC 2860 (the Memorandum of Understanding between the IETF and ICANN)", <http://iaoc.ietf.org/contracts.html>. [NTIA-Announce] NTIA, "NTIA Announces Intent to Transition Key Internet Domain Name Functions", March 2014, <http://www.ntia.doc.gov/press-release/2014/ntia- announces-intent-transition-key-internet-domain-name- functions>. [NTIA-Contract] NTIA, "The NTIA Contract with ICANN", <http://www.ntia.doc.gov/files/ntia/publications/ sf_26_pg_1-2-final_award_and_sacs.pdf>. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <http://www.rfc-editor.org/info/rfc2026>. [RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, September 1998, <http://www.rfc-editor.org/info/rfc2418>. [RFC2850] Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000, <http://www.rfc-editor.org/info/rfc2850>. [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, DOI 10.17487/RFC2860, June 2000, <http://www.rfc-editor.org/info/rfc2860>. [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, <http://www.rfc-editor.org/info/rfc3307>. [RFC3777] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", RFC 3777, DOI 10.17487/RFC3777, June 2004, <http://www.rfc-editor.org/info/rfc3777>. [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, <http://www.rfc-editor.org/info/rfc3935>.
[RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, DOI 10.17487/RFC4071, April 2005, <http://www.rfc-editor.org/info/rfc4071>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010, <http://www.rfc-editor.org/info/rfc5771>. [RFC6220] McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed., Huston, G., Ed., and Internet Architecture Board, "Defining the Role and Function of IETF Protocol Parameter Registry Operators", RFC 6220, DOI 10.17487/RFC6220, April 2011, <http://www.rfc-editor.org/info/rfc6220>. [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, <http://www.rfc-editor.org/info/rfc6761>. [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>. [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 7282, DOI 10.17487/RFC7282, June 2014, <http://www.rfc-editor.org/info/rfc7282>.7.2. Informative References
[I-D.leiba-cotton-iana-5226bis] Cotton, M., Leiba, B., and D. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", Work in Progress, draft-leiba-cotton-iana-5226bis-17, July 2016.
[ICG-Response] IANA Stewardship Transition Coordination Group, "Proposal to Transition the Stewardship of the Internet Assigned Numbers Authority (IANA) Functions from the U.S. Commerce Department's National Telecommunications and Information Administration (NTIA) to the Global Multistakeholder Community", 11 March 2016, <https://www.icann.org/en/system/files/files/ iana-stewardship-transition-proposal-10mar16-en.pdf>. [ProtoParamEvo14] IAB Chair, "Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries", March 2014, <http://mailarchive.ietf.org/arch/msg/ internetgovtech/4EQ4bnEfE5ZkrPAtSAO2OBZM03k>. [RFC-INDEX] RFC Editor, "RFC Index", <http://www.rfc-editor.org/rfc/rfc-index.txt>. [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014, October 1996, <http://www.rfc-editor.org/info/rfc2014>. [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root Name Server Operational Requirements", RFC 2870, DOI 10.17487/RFC2870, June 2000, <http://www.rfc-editor.org/info/rfc2870>. [RFC3172] Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, September 2001, <http://www.rfc-editor.org/info/rfc3172>. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>. [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>. [RFC6852] Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St.Amour, "Affirmation of the Modern Paradigm for Standards", RFC 6852, DOI 10.17487/RFC6852, January 2013, <http://www.rfc-editor.org/info/rfc6852>.
[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The Internet Numbers Registry System", RFC 7020, DOI 10.17487/RFC7020, August 2013, <http://www.rfc-editor.org/info/rfc7020>. [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, DOI 10.17487/RFC7249, May 2014, <http://www.rfc-editor.org/info/rfc7249>.
Appendix A. The Charter of the IANA Stewardship Coordination Group (ICG)
Charter for the IANA Stewardship Transition Coordination Group V.10 (August 27, 2014) The IANA stewardship transition coordination group (ICG) has one deliverable: a proposal to the U.S. Commerce Department National Telecommunications and Information Administration (NTIA) regarding the transition of NTIA's stewardship of the IANA functions to the global multi-stakeholder community. The group will conduct itself transparently, consult with a broad range of stakeholders, and ensure that its proposals support the security and stability of the IANA functions. The group's mission is to coordinate the development of a proposal among the communities affected by the IANA functions. The IANA functions are divided into three main categories: domain names, number resources, and other protocol parameters. The domain names category falls further into the country code and generic domain name sub-categories. While there is some overlap among all of these categories, each poses distinct organizational, operational and technical issues, and each tends to have distinct communities of interest and expertise. For those reasons it is best to have work on the three categories of IANA parameters proceed autonomously in parallel and be based in the respective communities. The IANA stewardship transition process is taking place alongside a parallel and related process on enhancing ICANN accountability. While maintaining the accountability of Internet identifier governance is central to both processes, this group's scope is focused on the arrangements required for the continuance of IANA functions in an accountable and widely accepted manner after the expiry of the NTIA-ICANN contract. Nevertheless, the two processes are interrelated and interdependent and should appropriately coordinate their work. The coordination group has four main tasks: (i) Act as liaison to all interested parties, including the three "operational communities" (i.e., those with direct operational or service relationship with IANA; namely names, numbers, protocol parameters). This task consists of: a. Soliciting proposals from the operational communities b. Soliciting the input of the broad group of communities affected by the IANA functions (ii) Assess the outputs of the three operational communities for compatibility and interoperability
(iii) Assemble a complete proposal for the transition
(iv) Information sharing and public communication
Describing each in more detail:
(i) Liaison
a. Solicit proposals
The ICG expects a plan from the country code and generic name
communities (possibly a joint one), a plan from the numbers
community, and a plan from the protocol parameters community.
Members of the ICG will ensure that the communities from which they
are drawn are working on their part of the transition plans. This
involves informing them of requirements and schedules, tracking
progress, and highlighting the results or remaining issues. The role
of a coordination group member during this phase is to provide status
updates about the progress of his or her community in developing
their component, and to coordinate which community will develop a
transition proposal for each area of overlap (e.g., special-use
registry).
While working on the development of their proposals, the operational
communities are expected to address common requirements and issues
relating to the transition, in as far as they affect their parts of
the stewardship of IANA functions.
b. Solicit broader input
The ICG is open for input and feedback from all interested parties.
While no set of formal requirements related to a transition proposal
will be requested outside the operational communities, everyone's
input is welcome across all topics.
The ICG expects that all interested parties get involved as early as
possible in the relevant community processes. Input received
directly by the ICG may be referred to the relevant community
discussion.
The ICG members chosen from a particular community are the official
communication channel between the ICG and that community.
(ii) Assessment
When the group receives output from the communities it will discuss
and assess their compatibility and interoperability with the
proposals of the other communities. Each proposal should be
submitted with a clear record of how consensus has been reached for
the proposal in the community, and provide an analysis that shows the
proposal is in practice workable. The ICG should also compile the input it has received beyond the operational communities, and review the impacts of this input. The ICG might at some point detect problems with the component proposals. At that point the role of the ICG is to communicate that back to the relevant communities so that they (the relevant communities) can address the issues. It is not in the role of the ICG to develop proposals or to select from among competing proposals. (iii) Assembling and submitting a complete proposal The assembly effort involves taking the proposals for the different components and verifying that the whole fulfills the intended scope, meets the intended criteria, that there are no missing parts, and that the whole fits together. The whole also needs to include sufficient independent accountability mechanisms for running the IANA function. The ICG will then develop a draft final proposal that achieves rough consensus within the ICG itself. The ICG will then put this proposal up for public comment involving a reasonable period of time for reviewing the draft proposal, analyzing and preparing supportive or critical comments. The ICG will then review these comments and determine whether modifications are required. If no modifications are needed, and the coordination group agrees, the proposal will be submitted to NTIA. If changes are required to fix problems or to achieve broader support, the ICG will work with the operational communities in a manner similar to what was described in task (ii) above. Updates are subject to the same verification, review, and consensus processes as the initial proposals. If, in the ICG's opinion, broad public support for the proposal as articulated by the NTIA is not present, the parts of the proposal that are not supported return to the liaison phase. (iv) Information sharing The ICG serves as a central clearinghouse for public information about the IANA stewardship transition process. Its secretariat maintains an independent, publicly accessible and open website, under its own domain, where status updates, meetings and notices are announced, proposals are stored, the ICG members are listed, etc. As the development of the transition plans will take some time, it is important that information about ongoing work is distributed early and continuously. This will enable sharing of ideas and the detection of potential issues.
Appendix B. IANA Stewardship Transition Coordination Group Request for Proposals
IANA Stewardship Transition Coordination Group Request for Proposals 8 September 2014 Introduction Under the IANA Stewardship Transition Coordination Group (ICG) Charter, the ICG has four main tasks: (i) Act as liaison to all interested parties in the IANA stewardship transition, including the three "operational communities" (i.e., those with direct operational or service relationships with the IANA functions operator; namely names, numbers, protocol parameters). This task consists of: a. Soliciting proposals from the operational communities b. Soliciting the input of the broad group of communities affected by the IANA functions (ii) Assess the outputs of the three operational communities for compatibility and interoperability (iii) Assemble a complete proposal for the transition (iv) Information sharing and public communication This Request for Proposals (RFP) addresses task (i) of the ICG Charter. This RFP does not preclude any form of input from the non-operational communities. 0. Complete Formal Responses The IANA Stewardship Transition Coordination Group (ICG) seeks complete formal responses to this RFP through processes which are to be convened by each of the "operational communities" of IANA (i.e., those with direct operational or service relationships with the IANA functions operator, in connection with names, numbers, or protocol parameters). Proposals should be supported by the broad range of stakeholders participating in the proposal development process. Proposals should be developed through a transparent process that is open to and inclusive of all stakeholders interested in participating in the development of the proposal. In order to help the ICG maintain its light coordination role, all interested and affected parties are
strongly encouraged to participate directly in these community processes. The following link provides information about ongoing community processes and how to participate in them, and that will continue to be updated over time: https://www.icann.org/en/stewardship/community In this RFP, "IANA" refers to the functions currently specified in the agreement between NTIA and ICANN [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as well as any other functions traditionally performed by the IANA functions operator. SAC-067 [https://www.icann.org/en/system/files/files/sac-067-en.pdf] provides one description of the many different meanings of the term "IANA" and may be useful reading in addition to the documents constituting the agreement itself. Communities are asked to adhere to open and inclusive processes in developing their responses, so that all community members may fully participate in and observe those processes. Communities are also asked to actively seek out and encourage wider participation by any other parties with interest in their response. A major challenge of the ICG will be to identify and help to reconcile differences between submitted proposals, in order to produce a single plan for the transition of IANA stewardship. Submitted Proposals should therefore focus on those elements that are considered to be truly essential to the transition of their specific IANA functions. The target deadline for all complete formal responses to this RFP is 15 January 2015. I. Comments While the ICG is requesting complete formal proposals through processes convened by each of the operational communities, and that all interested parties get involved as early as possible in the relevant community processes, some parties may choose to provide comments directly to the ICG about specific aspects of particular proposals, about the community processes, or about the ICG's own processes. Comments may be directly submitted to the ICG any time via email to icg-forum@icann.org. Comments will be publicly archived at <http://forum.icann.org/lists/icg-forum/>.
Commenters should be aware that ICG will direct comments received to
the relevant operational communities if appropriate. The ICG will
review comments received as time and resources permit and in
accordance with the overall timeline for the transition. That is,
comments received about specific proposals may not be reviewed until
those proposals have been submitted to the ICG. The ICG may
establish defined public comment periods about specific topics in
the future, after the complete formal responses to the RFP have been
received.
Required Proposal Elements
The ICG encourages each community to submit a single proposal that
contains the elements described in this section.
Communities are requested to describe the elements delineated in the
sections below in as much detail possible, and according to the
suggested format/structure, to allow the ICG to more easily
assimilate the results. While each question is narrowly defined to
allow for comparison between answers, respondents are encouraged to
provide further information in explanatory sections, including
descriptive summaries of policies/practices and associated
references to source documents of specific policies/practices. In
this way, the responses to the questionnaire will be useful at the
operational level as well as to the broader stakeholder communities.
In the interest of completeness and consistency, proposals should
cross-reference wherever appropriate the current IANA Functions
Contract[3] when describing existing arrangements and proposing
changes to existing arrangements.
0. Proposal type
Identify which category of the IANA functions this submission
proposes to address:
[ ] Names [ ] Numbers [ ] Protocol Parameters
I. Description of Community's Use of IANA Functions
This section should list the specific, distinct IANA functions your
community relies on. For each IANA function on which your community
relies, please provide the following:
o A description of the function;
o A description of the customer(s) of the function;
o What registries are involved in providing the function;
o A description of any overlaps or interdependencies between your
IANA requirements and the functions required by other customer
communities.
If your community relies on any other IANA service or activity
beyond the scope of the IANA functions contract, you may describe
them here. In this case please also describe how the service or
activity should be addressed by the transition plan.
II. Existing, Pre-Transition Arrangements
This section should describe how existing IANA-related arrangements
work, prior to the transition.
[3] http://www.ntia.doc.gov/files/ntia/
publications/sf_26_pg_1-2-final_award_and_sacs.pdf
A. Policy Sources
This section should identify the specific source(s) of policy which
must be followed by the IANA functions operator in its conduct of
the services or activities described above. If there are distinct
sources of policy or policy development for different IANA
functions, then please describe these separately. For each source of
policy or policy development, please provide the following:
o Which IANA function (identified in Section I) are affected.
o A description of how policy is developed and established and who
is involved in policy development and establishment.
o A description of how disputes about policy are resolved.
o References to documentation of policy development and dispute
resolution processes.
B. Oversight and Accountability
This section should describe all the ways in which oversight is
conducted over the IANA functions operator's provision of the
services and activities listed in Section I and all the ways in
which the IANA functions operator is currently held accountable for
the provision of those services. For each oversight or
accountability mechanism, please provide as many of the following as
are applicable:
Which IANA functions (identified in Section I) are affected. If the
policy sources identified in Section II.A are affected, identify
which ones are affected and explain in what way.
o A description of the entity or entities that provide oversight or
perform accountability functions, including how individuals are
selected or removed from participation in those entities.
o A description of the mechanism (e.g., contract, reporting scheme,
auditing scheme, etc.). This should include a description of the
consequences of the IANA functions operator not meeting the
standards established by the mechanism, the extent to which the
output of the mechanism is transparent and the terms under which
the mechanism may change.
o Jurisdiction(s) in which the mechanism applies and the legal basis
on which the mechanism rests.
III. Proposed Post-Transition Oversight and Accountability
Arrangements
This section should describe what changes your community is
proposing to the arrangements listed in Section II.B in light of the
transition. If your community is proposing to replace one or more
existing arrangements with new arrangements, that replacement should
be explained and all of the elements listed in Section II.B should
be described for the new arrangements. Your community should provide
its rationale and justification for the new arrangements.
If your community's proposal carries any implications for the
interface between the IANA functions and existing policy arrangements
described in Section II.A, those implications should be described
here.
If your community is not proposing changes to arrangements listed in
Section II.B, the rationale and justification for that choice should
be provided here.
IV. Transition Implications
This section should describe what your community views as the
implications of the changes it proposed in Section III. These
implications may include some or all of the following, or other
implications specific to your community:
Description of operational requirements to achieve continuity of
service and possible new service integration throughout the
transition.
Risks to operational continuity and how they will be addressed.
Description of any legal framework requirements in the absence of the
NTIA contract. Description of how you have tested or evaluated the
workability of any new technical or operational methods proposed in
this document and how they compare to established arrangements.
Description of how long the proposals in Section III are expected to
take to complete, and any intermediate milestones that may occur
before they are completed.
V. NTIA Requirements
Additionally, NTIA has established that the transition proposal must
meet the following five requirements:
o Support and enhance the multistakeholder model;
o Maintain the security, stability, and resiliency of the Internet
DNS;
o Meet the needs and expectation of the global customers and
partners of the IANA functions;
o Maintain the openness of the Internet;
o The proposal must not replace the NTIA role with a government-led
or an inter-governmental organization solution.
This section should explain how your community's proposal meets these
requirements and how it responds to the global interest in the IANA
functions.
VI. Community Process
This section should describe the process your community used for
developing this proposal, including:
o The steps that were taken to develop the proposal and to determine
consensus.
o Links to announcements, agendas, mailing lists, consultations and
meeting proceedings.
o An assessment of the level of consensus behind your community's
proposal, including a description of areas of contention or
disagreement.
Appendix C. Correspondence of the IETF to the ICG
The following messages were sent to the ICG: From: Jari Arkko <jari.arkko@piuha.net> Subject: Re: [Internal-cg] Question from the ICG Date: 20 Feb 2015 23:46:20 GMT+2 To: Alissa Cooper <alissa@cooperw.in>, ICG <internal-cg@icann.org> Cc: Izumi Okutani <izumi@nic.ad.jp> Dear Alissa and the ICG, We refer to the question that the ICG asked the IETF community on 9 Feb 2015 http://www.ietf.org/mail-archive/web/ianaplan/current/msg01610.html > The numbers proposal sees these changes as a requirement of the > transition and the protocols parameters proposal does not. If > these aspects of the proposals are perceived as incompatible would > the numbers and protocol parameters communities be willing to > modify their proposals to reconcile them? We do not observe incompatibilities between the proposals from the numbers and protocol parameters communities. The numbers community expresses a preference to transfer the trademark and domain, while the IETF proposal does not oppose such transfer. This is not an incompatibility, it is something that can be satisfied by implementation of both number and protocol parameters community's proposals, as already specified. To confirm this, and to determine whether the transfer of the trademark and domain would be acceptable, we consulted the community. It is the opinion of the IANAPLAN working group that they would support a decision by the IETF Trust to hold the trademark and domain on behalf of the Internet community. For details, see http://www.ietf.org/mail-archive/web/ianaplan/current/msg01659.html The IETF Trust also looked at this issue. The trustees decided that the IETF Trust would be willing to hold intellectual property rights relating to the IANA function, including the IANA trademark and the IANA.ORG domain name. For details, see http://www.ietf.org/mail-archive/web/ianaplan/current/msg01664.html In short, we find no incompatibility between the proposals and no need to modify the protocol parameters proposal.
Best Regards, Jari Arkko and Russ Housley on behalf of the IETF community and the IETF Trust From: Jari Arkko <jari.arkko@piuha.net> Subject: [Internal-cg] IETF response to the time frame inquiry Date: 5 Jun 2015 13:39:50 GMT+3 To: Alissa Cooper <alissa@cooperw.in> Cc: ICG <internal-cg@ianacg.org> This is a response to a query regarding transition finalisation and implementation time frames, sent to the IANAPLAN working group list by the chairs of the IANA Transition Coordination Group (ICG) on May 27th. While I am carrying this response back to the ICG, the substance of this response has been discussed in the IANAPLAN working group and the relevant parts of IETF leadership. I believe this response represents the (rough) consensus opinion that emerged in the discussion, as well as the current state of IANA arrangement updates that our leadership bodies have been working on. The IETF is ready today to take the next steps in the implementation of the transition of the stewardship. In our case, most of the necessary framework is already in place and implemented in preceding years. The remaining step is an updated agreement with ICANN which addresses two issues. These issues are outlined in Section 2.III in the Internet Draft draft-ietf-ianaplan-icg-response-09.txt: o The protocol parameters registries are in the public domain. It is the preference of the IETF community that all relevant parties acknowledge that fact as part of the transition. o It is possible in the future that the operation of the protocol parameters registries may be transitioned from ICANN to subsequent operator(s). It is the preference of the IETF community that, as part of the NTIA transition, ICANN acknowledge that it will carry out the obligations established under C.7.3 and I.61 of the current IANA functions contract between ICANN and the NTIA [NTIA-Contract] to achieve a smooth transition to subsequent operator(s), should the need arise. Furthermore, in the event of a transition it is the expectation of the IETF community that
ICANN, the IETF, and subsequent operator(s) will work together to minimize disruption in the use of the protocol parameters registries or other resources currently located at iana.org. The IETF Administrative Oversight Committee (IAOC) has decided to use an update of our yearly IETF-ICANN Service Level Agreement (SLA) as the mechanism for this updated agreement. They have drafted the update and from our perspective it could be immediately executed. Once the updated agreement is in place, the transition would be substantially complete, with only the NTIA contract lapse or termination as a final step. Of course, we are not alone in this process. Interactions with other parts of the process may bring additional tasks that need to be executed either before or after the transition. First, the ICG, the RIRs, and IETF have discussed the possibility of aligning the treatment of IANA trademarks and domains. The IETF Trust has signalled that it would be willing to do this, if asked. We are awaiting coordination on this to complete, but see no problem in speedy execution once the decision is made. From our perspective this is not a prerequisite for the transition, however. In addition, the names community has proposed the creation of a 'Post Transition IANA' (PTI). If the existing agreements between the IETF and ICANN remain in place and the SLAs discussed above are not affected, the IETF transition would take place as described above. That is our preference. If the final details of the PTI plan require further action from the IETF, more work and community agreement would be required. The timeline for that work cannot be set until the scope is known. Jari Arkko, IETF Chair (reporting his summary of the situation) From: Jari Arkko <jari.arkko@piuha.net> Subject: [Internal-cg] Response from IETF IANAPLAN WG regarding the ICG question on coordination Date: 8 Oct 2015 10:13:07 GMT+3 To: IANA etc etc Coordination Group <internal-cg@ianacg.org> The IANAPLAN working group has discussed the coordination question from the ICG. In the working group's opinion,
informal coordination exists today and will continue, which is consistent with the commitment requested by the ICG. This is also consistent with an overall coordination commitment already indicated in the IANAPLAN proposal. The proposal is a consensus document of the IETF. From the proposal: The IETF will continue to coordinate with ICANN, the RIRs, and other parties that are mutually invested in the continued smooth operation of the Internet registries. The coordination approach is also consistent with the comments that were sent by the IAB to the ICG during the public comment period. See https://www.iab.org/documents/correspondence-reports-documents/2015- 2/iab-comments-on-icg-proposal/. Jari Arkko, IETF Chair and the Area Director for the IANAPLAN WGAuthors' Addresses
Eliot Lear (editor) Richtistrasse 7 Wallisellen, ZH CH-8304 Switzerland Phone: +41 44 878 9200 Email: lear@cisco.com Russ Housley (editor) 918 Spring Knoll Drive Herndon, VA 20170 United States of America Email: housley@vigilsec.com