ianaplanwg-v00.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 will review, comment on, evaluate, and if need be prepare text | The IANAPLAN working group is chartered to produce an IETF consensus | |||
for a proposal about protocol parameters registries. It will assume | document that describes the expected interaction between the IETF and | |||
the following documents continue to be in effect: | the operator of IETF protocol parameters registries. | |||
- RFC 2850 (especially section 2(d)) | The system in place today for oversight of the IETF protocol | |||
registries component of the IANA function works well. As a result, | ||||
minimal change in the oversight of the IETF protocol parameters | ||||
registries is preferred in all cases and no change is preferred when | ||||
possible. The working group will address the implications of moving | ||||
the NTIA out of its current role with respect to IANA on the IETF | ||||
protocol parameters registry function in a way that focuses on | ||||
continuation of the current arrangements. The working group will | ||||
assume the following documents continue to be in effect: | ||||
- RFC 2850 | ||||
- 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/2014-ICANN-IETF-MoU-Supplemental-Agreement-Executed.pdf) | http://iaoc.ietf.org/documents/ | |||
2014-ICANN-IETF-MoU-Supplemental-Agreement-Executed.pdf) | ||||
It is possible that RFC 3777 and its updates are also implicated. | ||||
This work is chartered exclusively to create the proposal that is | 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 | |||
outcomes should be pursued, even if the eventual structure (without | aside for future consideration. However, the mechanisms required to | |||
the overarching NTIA contract) requires procedural changes in order to | address the removal of the overarching NTIA contract may require | |||
address the new structure. | additional documentation or agreements. | |||
The WG will also review, comment on, and evaluate proposals from other | Should proposals made by other communities regarding the | |||
communities about the NTIA transition, to the extent that those | transition of other IANA functions affect the IETF protocol parameter | |||
proposals impinge on the protocol parameters registries or the IETF. | registries or the IETF, the WG may also review and comment on them. | |||
The results of any WG consensus on protocol parameters registries | Some parts of the transition proposal may need to document detailed | |||
will, of necessity, be input but not necessarily firm restrictions on | terms of agreements or other details of procedures that are normally | |||
any contractual terms that are ultimately adopted by the IAB and any | delegated to and handled by the IAB or IAOC. The working group will | |||
future IANA functions provider, or contractual terms ultimately | not attempt to produce or discuss documentation for these details, but | |||
adopted by the IAOC and any future IANA functions provider. | will request the IAB or IAOC to provide them ready for submission as | |||
Statements of principle and desired outcomes are more important items | part of the final proposal. | |||
to be delivered by the working group than are detailed terms for | ||||
future agreements. | ||||
It is expected that much of the work of the WG will lie in reviewing | The WG shall seek the expertise of the IAB IANA Strategy Program to | |||
materials produced by the IAB in its role as the interface to other | formulate its output. It is expected that members of the IAB IANA | |||
organizations. | 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 | |||
Sept 2015 -- close | Sept 2015 -- close | |||
End of changes. 10 change blocks. | ||||
44 lines changed or deleted | 55 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/ |