ianaplanwg-v05.txt | ianaplanwg-v06.txt | |||
---|---|---|---|---|
Area: General | Area: General | |||
Responsible AD: Jari Arkko | Responsible AD: Jari Arkko | |||
Chairs: TBD | Chairs: TBD | |||
Background | Background | |||
========== | ========== | |||
The IETF stores parameters for protocols it defines in registries. | Registries of parameter values for use in IETF protocols are stored | |||
These registries are maintained by the Internet Assigned Numbers | and maintainted for the IETF by the Internet Assigned Numbers | |||
Authority (IANA), and are the subject of the "IANA Considerations" | Authority (IANA), and are the subject of the "IANA Considerations" | |||
section in many RFCs. | section in many RFCs. | |||
For a number of years, the IANA function has been provided by the | For a number of years, maintenance of the IETF protocol parameters | |||
Internet Corporation for Assigned Names and Numbers (ICANN). The | registries has been provided by the Internet Corporation for Assigned | |||
IETF's relationship with IANA was formalized through a Memorandum of | Names and Numbers (ICANN). The IETF's relationship with IANA was | |||
Understanding codified in 2000 with the publication of RFC 2860; over | formalized through a Memorandum of Understanding between the IETF and | |||
time processes and role definitions have evolved, and have been | ICANN codified in 2000 with the publication of RFC 2860. Over time, | |||
documented in supplemental agreements. | processes and role definitions have evolved, and have been documented | |||
in supplemental agreements. | ||||
ICANN has historically had a contract with the US Department of | ICANN has had a contract with the US Department of Commerce (DoC) to | |||
Commerce (DoC), undertaken through the National Telecommunications and | provide the IANA function, undertaken through the National | |||
Information Administration (NTIA). In March of 2014, NTIA announced | Telecommunications and Information Administration (NTIA). In March of | |||
its intention to complete the evolution begun in 1997, meaning that | 2014, NTIA announced its intention to transition out of its current | |||
NTIA would not need to renew its contract with ICANN when that | role, meaning that NTIA would not need to renew its contract with | |||
contract expires 30 September 2015. NTIA requested a transition | ICANN when that contract expires 30 September 2015. NTIA requested a | |||
proposal be prepared to outline the necessary arrangements. In the | transition proposal be prepared to outline the necessary | |||
case of the IETF, we expect these arrangements to consist largely of | arrangements. In the case of the elements of the IANA function | |||
the existing well-documented practices. | concerning the IETF protocol registries, it is likely that the | |||
existing well-documented practices will continue and no or little new | ||||
activity will be required. | ||||
Tasks | Tasks | |||
===== | ===== | |||
The WG's output is expected to be an IETF consensus document that | The IANAPLAN working group is chartered to produce an IETF consensus | |||
describes the expected interaction between the IETF and the protocol | document that describes the expected interaction between the IETF and | |||
parameters registries operator. | the operator of IETF protocol parameters registries. | |||
Given that we have a system today that works well for the IETF, | The system in place today for oversight of the IETF protocol | |||
minimal change in the oversight of the protocol parameters registries | registries component of the IANA function works well. As a result, | |||
is preferred in all cases and no change is preferred when possible. | minimal change in the oversight of the IETF protocol parameters | |||
With a view to addressing implications of moving the NTIA out of its | registries is preferred in all cases and no change is preferred when | |||
current role with respect to IANA on the IETF protocol parameter | possible. The working group will address the implications of moving | |||
registry function, the WG will focus on documenting and ensuring the | the NTIA out of its current role with respect to IANA on the IETF | |||
continuation of the current arrangements. The | protocol parameters registry function in a way that focuses on | |||
working group will assume the following documents continue to be in | continuation of the current arrangements. The working group will | |||
effect: | assume the following documents continue to be in effect: | |||
- RFC 2850 | - RFC 2850 | |||
- RFC 3777 and its updates | - RFC 3777 and its updates | |||
- RFC 2860 | - RFC 2860 | |||
- RFC 6220 | - RFC 6220 | |||
- IETF-ICANN-MOU_2000 | - IETF-ICANN-MOU_2000 | |||
(http://iaoc.ietf.org/documents/IETF-ICANN-MOU_2000.pdf) | (http://iaoc.ietf.org/documents/IETF-ICANN-MOU_2000.pdf) | |||
- ICANN-IETF Supplemental Agreements | - ICANN-IETF Supplemental Agreements | |||
(updated yearly since 2007, the 2014 version is available at | (updated yearly since 2007, the 2014 version is available at | |||
http://iaoc.ietf.org/documents/ | http://iaoc.ietf.org/documents/ | |||
2014-ICANN-IETF-MoU-Supplemental-Agreement-Executed.pdf) | 2014-ICANN-IETF-MoU-Supplemental-Agreement-Executed.pdf) | |||
This working group is chartered solely with respect to the planning | This working group is chartered solely with respect to the planning | |||
needed for the transition. Possible improvements outside that scope | needed for the transition, and is not meant to cover other topics | |||
will be set aside for future consideration. Avoiding alterations in | related to IANA. Possible improvements outside that scope will be set | |||
substantive outcomes should be the goal, even if eventual mechanisms | aside for future consideration. However, the mechanisms required to | |||
required to address the removal of the overarching NTIA contract | address the removal of the overarching NTIA contract may require | |||
may require additional documentation or agreements. | additional documentation or agreements. | |||
Should proposals made to the NTIA by other communities regarding the | Should proposals made by other communities regarding the | |||
transition of other IANA functions affect the protocol parameter | transition of other IANA functions affect the IETF protocol parameter | |||
registries or the IETF, the WG will also review and comment on them. | registries or the IETF, the WG may also review and comment on them. | |||
The output document of the WG need not be the complete transition | Some parts of the transition proposal may need to document detailed | |||
proposal regarding the oversight of the protocol parameters registries | terms of agreements or other details of procedures that are normally | |||
to be handed to the NTIA. Specifically, if that transition proposal | delegated to and handled by the IAB or IAOC. The working group will | |||
requires documentation of some detailed terms of agreements or other | not attempt to produce or discuss documentation for these details, but | |||
details of procedures that are normally delegated to and handled by | will request the IAB or IAOC to provide them ready for submission as | |||
the IAB or IAOC, the IAB or IAOC can provide those details as part of | part of the final proposal. | |||
the submission; the WG does not need to come to consensus on those | ||||
parts of the submission. | ||||
The WG shall seek the expertise of the IAB IANA Strategy Program to | The WG shall seek the expertise of the IAB IANA Strategy Program to | |||
formulate its output. It is expected that members of the IAB IANA | formulate its output. It is expected that members of the IAB IANA | |||
Strategy Program will actively participate in the WG. | Strategy Program will actively participate in the WG. | |||
Milestones | Milestones | |||
========== | ========== | |||
January 2015 -- complete protocol parameters registries proposal | January 2015 -- complete protocol parameters registries proposal | |||
May 2015 -- review of other transition proposals, if needed | May 2015 -- review of other transition proposals, if needed | |||
End of changes. 8 change blocks. | ||||
45 lines changed or deleted | 46 lines changed or added | |||
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |