< draft-ietf-ianaplan-icg-response-02.txt   draft-ietf-ianaplan-icg-response-03.txt >
IANAPLAN E. Lear, Ed. IANAPLAN E. Lear, Ed.
Internet-Draft R. Housley, Ed. Internet-Draft R. Housley, Ed.
Intended status: Informational October 27, 2014 Intended status: Informational November 14, 2014
Expires: April 30, 2015 Expires: May 18, 2015
Draft Response to the Internet Coordination Group Request for Proposals Draft Response to the Internet Coordination Group Request for Proposals
on IANA on the IANA protocol parameters registries
draft-ietf-ianaplan-icg-response-02 draft-ietf-ianaplan-icg-response-03
Abstract Abstract
This document contains the a response to a request for proposals from This document contains the a response to a request for proposals from
the IANA Stewardship Transition Coordination Group regarding the the IANA Stewardship Transition Coordination Group regarding the
protocol parameters registries. It is meant to be included in an protocol parameters registries. It is meant to be included in an
aggregate proposal that also includes contributions covering domain aggregate proposal that also includes contributions covering domain
names and numbering resources that will be submitted from their names and numbering resources that will be submitted from their
respective operational communities. The IETF community is invited to respective operational communities. The IETF community is invited to
comment and propose changes to this document. comment and propose changes to this document.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2015. This Internet-Draft will expire on May 18, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. IETF Introduction . . . . . . . . . . . . . . . . . . . . . . 2 1. IETF Introduction . . . . . . . . . . . . . . . . . . . . . . 2
2. The Formal RFP Response . . . . . . . . . . . . . . . . . . . 3 2. The Formal RFP Response . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 5. IAB Note . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Informative References . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
7. Informative References . . . . . . . . . . . . . . . . . . . 17
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 19
A.1. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 19 A.1. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 19
A.2. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 20 A.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 20
A.3. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 20
Appendix B. The Charter of the IANA Stewardship Coordination Appendix B. The Charter of the IANA Stewardship Coordination
Group (ICG . . . . . . . . . . . . . . . . . . . . . 20 Group (ICG . . . . . . . . . . . . . . . . . . . . . 20
Appendix C. IANA Stewardship Transition Coordination Group Appendix C. IANA Stewardship Transition Coordination Group
Request for Proposals . . . . . . . . . . . . . . . 23 Request for Proposals . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. IETF Introduction 1. IETF Introduction
In March of 2014 the U.S. National Telecommunications & Information In March of 2014 the U.S. National Telecommunications & Information
Administration (NTIA) announced its intent to transition oversight of Administration (NTIA) announced its intent to transition oversight of
Internet Assigned Numbers Authority (IANA) functions. In that Internet Assigned Numbers Authority (IANA) functions. In that
announcement, NTIA asked the Internet Corporation for Assigned Names announcement, NTIA asked the Internet Corporation for Assigned Names
and Numbers (ICANN) to establish a process to deliver a proposal for and Numbers (ICANN) to establish a process to deliver a proposal for
transition. As part of that process, the IANA Stewardship Transition transition. As part of that process, the IANA Stewardship Transition
Coordination Group (ICG) was formed. The charter for the ICG can be Coordination Group (ICG) was formed. The charter for the ICG can be
found in Appendix B. They solicited proposals regarding the found in Appendix B. They solicited proposals regarding post-
respective functions that IANA performs, in order that they may put transition arrangements from the three functional areas in order to
forth a proposal to the NTIA. The final request for proposal (RFP) put forth a proposal to the NTIA. The final request for proposal
can be found in Appendix C. (RFP) can be found in Appendix C.
While there are interactions between all of the IANA functions and While there are interactions between all of the IANA functions and
IETF standards, this document specifically addresses the protocol IETF standards, this document specifically addresses the protocol
parameters registries function. Section 1 (this section) contains an parameters registries function. Section 1 (this section) contains an
introduction that is sourced solely within the IETF. Section 2 introduction that is sourced solely within the IETF. Section 2
contains the questionnaire that was written by the ICG and a formal contains the questionnaire that was written by the ICG and a formal
response by the IETF. Because much of this memo is taken from a response by the IETF. Because much of this memo is taken from a
questionnaire we have quoted questions with ">>> " and we have questionnaire we have quoted questions with ">>> " and we have
prefaced answers to questions being asked with "IETF Response:". prefaced answers to questions being asked with "IETF Response:".
Note that there are small changes to the content of the questions Note that there are small changes to the content of the questions
skipping to change at page 4, line 4 skipping to change at page 4, line 7
>>> >>>
IETF Response: IETF Response:
Many IETF protocols make use of commonly defined protocol parameters. Many IETF protocols make use of commonly defined protocol parameters.
These parameters are used by implementers, who are the IETF's primary These parameters are used by implementers, who are the IETF's primary
users of the IETF standards and other documents. To ensure users of the IETF standards and other documents. To ensure
consistent interpretation of these parameter values by independent consistent interpretation of these parameter values by independent
implementations, and to promote universal interoperability, these implementations, and to promote universal interoperability, these
IETF protocol specifications define and require globally available IETF protocol specifications define and require globally available
registries containing the parameter values and a pointer to registries containing the parameter values and a pointer to any
documentation of the associated semantic intent. The IETF uses the associated documentation. The IETF uses the IANA protocol parameters
IANA protocol parameters registries to store this information in a registries to store this information in a public location. The IETF
public location. community presently accesses the protocol parameter registries via
references based on iana.org domain name, and makes use of the term
"IANA" in the protocol parameter registry processes[RFC5226].
ICANN currently operates the .ARPA top level domain on behalf of the
Internet Architecture Board (IAB). This zone is used for certain
Internet infrastructure services that are delegated beneath it. We
consider .ARPA part of the protocol parameters registries for
purposes of this response.
>>> >>>
>>> A description of the customer(s) of the service or activity. >>> A description of the customer(s) of the service or activity.
>>> >>>
IETF Response: IETF Response:
The IANA protocol parameters registries operator maintains the The IANA protocol parameters registries operator maintains the
protocol parameters registries for the IETF in accordance with all protocol parameters registries for the IETF in conformance with all
relevant IETF policies, in accordance with the Memorandum of relevant IETF policies, in accordance with the Memorandum of
Understanding[RFC2860] and associated supplemental agreements that Understanding[RFC2860] and associated supplemental agreements that
include service level agreements (SLAs) established between the IETF include service level agreements (SLAs) established between the IETF
and ICANN[MOUSUP]. and ICANN[MOUSUP].
The IETF is a global voluntary standards organization whose goal is The IETF is a global voluntary standards organization whose goal is
to make the Internet work better [RFC3595]. IETF standards are to make the Internet work better [RFC3595]. IETF standards are
published in the RFC series. The IETF is responsible for the key published in the RFC series. The IETF is responsible for the key
standards that are used on the Internet today, including IP, TCP, standards that are used on the Internet today, including IP, TCP,
DNS, BGP, and HTTP, to name but a few. DNS, BGP, and HTTP, to name but a few.
skipping to change at page 4, line 40 skipping to change at page 5, line 4
The Internet Standards Process is documented in [RFC2026]. That The Internet Standards Process is documented in [RFC2026]. That
document explains not only how standards are developed, but also how document explains not only how standards are developed, but also how
disputes about decisions are resolved. RFC 2026 has been amended a disputes about decisions are resolved. RFC 2026 has been amended a
number of times, and those amendments are indicated in [RFC-INDEX]. number of times, and those amendments are indicated in [RFC-INDEX].
The standards process can be amended in the same manner that The standards process can be amended in the same manner that
standards are approved. That is, someone proposes a change by standards are approved. That is, someone proposes a change by
submitting a temporary document known as an Internet-Draft, the submitting a temporary document known as an Internet-Draft, the
community discusses it, and if rough consensus can be found the community discusses it, and if rough consensus can be found the
change is approved by the Internet Engineering Steering Group (IESG), change is approved by the Internet Engineering Steering Group (IESG),
who also have day-to-day responsibility for declaring IETF consensus who also have day-to-day responsibility for declaring IETF consensus
on technical decisions, including those that affect IANA. Anyone may on technical decisions, including those that affect the IANA protocol
propose a change during a Last Call, and anyone may participate in parameters registries. Anyone may propose a change during a Last
the community discussion. Call, and anyone may participate in the community discussion.
>>> >>>
>>> What registries are involved in providing the service or >>> What registries are involved in providing the service or
>>> activity. >>> activity.
>>> >>>
IETF Response: IETF Response:
The protocol parameters registries are the product of IETF work. The protocol parameters registries are the product of IETF work.
These also include the top-level registry for the entire IP address
space and some of its sub-registries, AS number space, and a number
of special use registries with regard to domain names. For more
detail please refer to the documentation in the "overlaps or
interdependencies" section.
Administration of the protocol parameters registries is the service Administration of the protocol parameters registries is the service
that is provided to the IETF. that is provided to the IETF.
>>> >>>
>>> A description of any overlaps or interdependencies between your >>> A description of any overlaps or interdependencies between your
>>> IANA requirements and the functions required by other customer >>> IANA requirements and the functions required by other customer
>>> communities >>> communities
>>> >>>
IETF Response: IETF Response:
In this context, the IETF considers "overlap" to be where there is in In this context, the IETF considers "overlap" to be where there is in
some way shared responsibility for a single registry across multiple some way shared responsibility for a single registry across multiple
organizations. In this sense, there is no overlap between organizations. In this sense, there is no overlap between
organizations because responsibility for each registry is carefully organizations because responsibility for each registry is carefully
delineated. There are, however, points of interaction between other delineated. There are, however, points of interaction between other
organizations, and a few cases where we may further define the scope organizations, and a few cases where we may further define the scope
of a registry for technical purposes. This is the case with both of a registry for technical purposes. This is the case with both
names and numbers, as described in the paragraphs below. In all names and numbers, as described in the paragraphs below. In all
cases, the IETF engages directly with the appropriate organizations cases, the IETF coordinates with the appropriate organizations.
to ensure that each organization's policies are followed.
It is important to note that the IETF includes anyone who wishes to It is important to note that the IETF includes anyone who wishes to
participate. Staff and participants from ICANN or the Regional participate. Staff and participants from ICANN or the Regional
Internet Registries (RIRs) regularly participate in IETF activities. Internet Registries (RIRs) regularly participate in IETF activities.
o The IETF has specified a number of special use registries with o The IETF has specified a number of special use registries with
regard to domain names. These registries require coordination regard to domain names. These registries require coordination
with the Generic Names Support Organization (GNSO). We already with ICANN as the policy authority for the DNS root, including
perform this coordination.[RFC6761] community groups that are responsible for ICANN policy on domain
names such as the GNSO and the ccNSO. There are already
mechanisms in place to perform this coordination, and the capacity
to modify them to meet new conditions as they might
arise.[RFC6761]
o The IETF specifies the DNS protocol. From time to time there have o The IETF specifies the DNS protocol. From time to time there have
been and will be updates to that protocol. As we make changes we been and will be updates to that protocol. As we make changes we
will broadly consult the operational community about the impact of will broadly consult the operational community about the impact of
those changes, as we have done in the past. those changes, as we have done in the past.
o The IETF specifies minimum requirements for root servers. Should o The IETF specifies minimum requirements for root servers. Should
those requirements change, we will inform ICANN. those requirements change, we will inform ICANN.
o The routing architecture has evolved over time, and is expected to o The routing architecture has evolved over time, and is expected to
continue to do so. Such evolution may have an impact on continue to do so. Such evolution may have an impact on
appropriate IP address allocation strategies. As and when that appropriate IP address allocation strategies. As and when that
happens, we will consult with the RIR community, as we have done happens, we will consult with the RIR community, as we have done
in the past. in the past.
o The IETF is responsible for policy relating to the entire IP o The IETF is responsible for policy relating to the entire IP
address space and AS number space. Through IANA, the IETF address space and AS number space. Through the IANA protocol
delegates unicast IP address and AS number ranges to the RIR parameters registries, the IETF delegates unicast IP address and
system [RFC7020],[RFC7249]. Special address allocation, such a AS number ranges to the RIR system [RFC7020],[RFC7249]. Special
multicast and anycast addresses, often require coordination. address allocation, such a multicast and anycast addresses, often
Another example of IP addresses that are not administered by the require coordination. Another example of IP addresses that are
RIR system is Unique Local Addresses (ULAs) [RFC4193], where local not administered by the RIR system is Unique Local Addresses
networks employ a prefix that is not intended to be routed on the (ULAs) [RFC4193], where local networks employ a prefix that is not
public Internet. New special address allocations are added, from intended to be routed on the public Internet. New special address
time to time, related to the evolution of the standards. In all allocations are added, from time to time, related to the evolution
cases, these special assignments are listed in the IANA of the standards. In all cases, these special assignments are
registries. listed in the IANA protocol paramters registries.
o The IETF maintains sub-registries for special IPv4 and IPv6 o The IETF maintains sub-registries for special IPv4 and IPv6
assignments. These are specified in [RFC3307], [RFC5771], and assignments. These are specified in [RFC3307], [RFC5771], and
[RFC6890]. The IETF coordinates such assignments with the RIRs. [RFC6890]. The IETF coordinates such assignments with the RIRs.
o IETF standards changes may have impact on operations of RIRs and o IETF standards changes may have impact on operations of RIRs and
service providers. A recent example is the extensions to BGP to service providers. A recent example is the extensions to BGP to
carry the Autonomous System numbers as four-octet entities carry the Autonomous System numbers as four-octet entities
[RFC6793]. It is important to note that this change occurred out [RFC6793]. It is important to note that this change occurred out
of operational necessity, and it demonstrated strong alignment of operational necessity, and it demonstrated strong alignment
skipping to change at page 7, line 12 skipping to change at page 7, line 30
IETF Response: The protocol parameters registries. IETF Response: The protocol parameters registries.
>>> >>>
>>> A description of how policy is developed and established and >>> A description of how policy is developed and established and
>>> who is involved in policy development and establishment. >>> who is involved in policy development and establishment.
>>> >>>
IETF Response: IETF Response:
Policy for overall management of the registries is stated in Policy for overall management of the protocol parameters registries
[RFC6220] and [RFC5226]. The first of these documents explains the is stated in [RFC6220] and [RFC5226]. The first of these documents
model for how the registries are to be operated, how policy is set, explains the model for how the registries are to be operated, how
and how oversight takes place. RFC 5226 specifies the policies that policy is set, and how oversight takes place. RFC 5226 specifies the
specification writers may employ when they define new protocol policies that specification writers may employ when they define new
registries in the "IANA Considerations" section of each protocol registries in the "IANA Considerations" section of each
specification. All policies at the IETF begin with a proposal in the specification. All policies at the IETF begin with a proposal in the
form of an Internet-Draft. Anyone may submit such a proposal. If form of an Internet-Draft. Anyone may submit such a proposal. If
there is sufficient interest, the Internet Engineering Steering Group there is sufficient interest, a working group whose scope includes
may choose to create a working group or an Area Director may choose the proposed work may choose to adopt it, the Internet Engineering
to sponsor the draft. In either case, anyone may comment on the Steering Group may choose to create a working group, or an Area
proposal as it progresses. A proposal cannot be passed by the IESG Director may choose to sponsor the draft. In any case, anyone may
unless it enjoys sufficient community support as to indicate rough comment on the proposal as it progresses. A proposal cannot be
consensus [RFC7282]. In each case, a "Last Call" is made so that passed by the IESG unless it enjoys sufficient community support as
there is notice of any proposed change to a policy or process. to indicate rough consensus [RFC7282]. In each case, a "Last Call"
Anyone may comment during a Last Call. is made so that there is notice of any proposed change to a policy or
process. Anyone may comment during a Last Call.
>>> >>>
>>> A description of how disputes about policy are resolved. >>> A description of how disputes about policy are resolved.
>>> >>>
IETF Response: IETF Response:
Most disputes are handled at the lowest level through the working Most disputes are handled at the lowest level through the working
group and rough consensus processes. Should anyone disagree with any group and rough consensus processes. Should anyone disagree with any
action, Section 6.5 of [RFC2026] specifies a multi-level conflict action, Section 6.5 of [RFC2026] specifies a multi-level conflict
resolution and appeals process that includes the responsible Area resolution and appeals process that includes the responsible Area
Director, the IESG, and the IAB. Should appeals be upheld, an Director, the IESG, and the IAB. Should appeals be upheld, an
appropriate remedy is applied. In the case where someone claims that appropriate remedy is applied. In the case where someone claims that
skipping to change at page 8, line 30 skipping to change at page 9, line 4
>>> >>>
>>> Which IANA service or activity (identified in Section I) is >>> Which IANA service or activity (identified in Section I) is
>>> affected. >>> affected.
>>> >>>
IETF Response: the protocol parameters registries. IETF Response: the protocol parameters registries.
>>> >>>
>>> If not all policy sources identified in Section II.A are >>> If not all policy sources identified in Section II.A are
>>> affected, identify which ones are affected. >>> affected, identify which ones are affected.
>>> >>>
IETF Response: all policy sources relating to the protocol parameters IETF Response: all policy sources relating to the protocol parameters
registry are affected. registry are affected.
>>> >>>
>>> A description of the entity or entities that provide oversight >>> A description of the entity or entities that provide oversight
>>> or perform accountability functions, including how individuals >>> or perform accountability functions, including how individuals
>>> are selected or removed from participation in those entities. >>> are selected or removed from participation in those entities.
>>> >>>
IETF Response: IETF Response:
The Internet Architecture Board (IAB) is an oversight body of the The Internet Architecture Board (IAB) is an oversight body of the
IETF whose responsibilities include, among other things, confirming IETF whose responsibilities include, among other things, confirming
appointment of IESG members, managing appeals as discussed above, appointment of IESG members, managing appeals as discussed above,
management of certain domains, including .ARPA [RFC3172], and general management of certain domains, including .ARPA [RFC3172], and general
architectural guidance to the broader community. The IAB must architectural guidance to the broader community. The IAB must
approve the appointment of an organization to act as IANA on behalf approve the appointment of an organization to act as IANA operator on
of the IETF. The IAB is also responsible for establishing liaison behalf of the IETF. The IAB is also responsible for establishing
relationships with other orgnaizations on behalf of the IETF. The liaison relationships with other orgnaizations on behalf of the IETF.
IAB's charter is to be found in [RFC2850]. The IAB's charter is to be found in [RFC2850].
The IAB members are selected and may be recalled through a Nominating The IAB members are selected and may be recalled through a Nominating
Committee (NOMCOM) process, which is described in [RFC3777]. This Committee (NOMCOM) process, which is described in [RFC3777]. This
process provides for selection of active members of the community who process provides for selection of active members of the community who
themselves agree upon a slate of candidates. Those candidates are themselves agree upon a slate of candidates. Those candidates are
sent to the Internet Society Board of Trustees for confirmation. In sent to the Internet Society Board of Trustees for confirmation. In
general, members serve for two years. The IAB selects its own chair. general, members are appointed for terms of two years. The IAB
selects its own chair.
The IAB provides oversight of the protocol parameters registries of The IAB provides oversight of the protocol parameters registries of
the IETF, and is responsible for selecting appropriate operator(s) the IETF, and is responsible for selecting appropriate operator(s)
and related per-registry arrangements. Especially when relationships and related per-registry arrangements. Especially when relationships
among protocols call for it, many registries are operated by, or in among protocols call for it, many registries are operated by, or in
conjunction with, other bodies. Unless the IAB or IETF has concluded conjunction with, other bodies. Unless the IAB or IETF has concluded
that special treatment is needed, the operator for registries is that special treatment is needed, the operator for registries is
currently ICANN. currently ICANN.
>>> >>>
skipping to change at page 9, line 30 skipping to change at page 10, line 4
that special treatment is needed, the operator for registries is that special treatment is needed, the operator for registries is
currently ICANN. currently ICANN.
>>> >>>
>>> A description of the mechanism (e.g., contract, reporting >>> A description of the mechanism (e.g., contract, reporting
>>> scheme, auditing scheme, etc.). This should include a >>> scheme, auditing scheme, etc.). This should include a
>>> description of the consequences of the IANA functions operator >>> description of the consequences of the IANA functions operator
>>> not meeting the standards established by the mechanism, the >>> not meeting the standards established by the mechanism, the
>>> extent to which the output of the mechanism is transparent and >>> extent to which the output of the mechanism is transparent and
>>> the terms under which the mechanism may change. >>> the terms under which the mechanism may change.
>>> >>>
IETF Response: IETF Response:
A memorandum of understanding (MoU) between ICANN and the IETF A memorandum of understanding (MoU) between ICANN and the IETF
community has been in place since 2000. It can be found in community has been in place since 2000. It can be found in
[RFC2860]. The MoU defines the work to be carried out by the IANA [RFC2860]. The MoU defines the work to be carried out by the IANA
staff for the IETF and the Internet Research Task Force (IRTF), a functions operator for the IETF and the Internet Research Task Force
peer organization to the IETF that focuses on research. Each year a (IRTF), a peer organization to the IETF that focuses on research.
service level agreement is negotiated that supplements the MoU. Each year a service level agreement is negotiated that supplements
the MoU.
Day-to-day administration and contract management is the Day-to-day administration and contract management is the
responsibility of the IETF Administrative Director (IAD). The IETF responsibility of the IETF Administrative Director (IAD). The IETF
Administrative Oversight Committee (IAOC) oversees the IAD. IAOC Administrative Oversight Committee (IAOC) oversees the IAD. The
members are appointed by the Internet Society Board of Trustees, the members of the IAOC are also the trustees of the IETF Trust, whose
IAB, the IESG, and the NOMCOM [RFC4071]. The IAOC works with the main purpose is to hold certain intellectual property for the benefit
IANA functions operator to establish annual IANA performance metrics of the IETF as a whole. IAOC members are appointed by the Internet
and operational procedures, and the resulting document is adopted as Society Board of Trustees, the IAB, the IESG, and the NOMCOM
an supplement to the MoU each year [MOUSUP]. In accordance with [RFC4071]. The IAOC works with the IANA functions operator to
these supplements, an annual review is performed to ensure that establish annual IANA performance metrics and operational procedures,
protocol parameter requests are being processed according to the and the resulting document is adopted as an supplement to the MoU
established policies. each year [MOUSUP]. In accordance with these supplements, an annual
review is performed to ensure that protocol parameter requests are
being processed according to the established policies.
To date there have been no unresolvable disputes or issues. In the To date there have been no unresolvable disputes or issues. In the
unlikely event that a more difficult situation should arise, the IAOC unlikely event that a more difficult situation should arise, the IAOC
and the IAB would engage ICANN management to address the matter. The and the IAB would engage ICANN management to address the matter. The
MoU also provides an option for either party to terminate the MoU also provides an option for either party to terminate the
arrangement with six months notice. Obviously such action would only arrangement with six months notice. Obviously such action would only
be undertaken after serious consideration. be undertaken after serious consideration.
>>> >>>
>>> Jurisdiction(s) in which the mechanism applies and the legal >>> Jurisdiction(s) in which the mechanism applies and the legal
skipping to change at page 11, line 10 skipping to change at page 11, line 25
>>> existing policy arrangements described in Section II.A, those >>> existing policy arrangements described in Section II.A, those
>>> implications should be described here. >>> implications should be described here.
>>> >>>
>>> If your community is not proposing changes to arrangements >>> If your community is not proposing changes to arrangements
>>> listed in Section II.B, the rationale and justification for that >>> listed in Section II.B, the rationale and justification for that
>>> choice should be provided here. >>> choice should be provided here.
>>> >>>
IETF Response: IETF Response:
No major changes are required, however, the IETF community has No major changes are required. Over the years since the creation of
expressed a desire for several points to be addressed by supplemental ICANN, the IETF, ICANN, and IAB have together created a system of
agreements to the IETF-ICANN MoU, prior to a transition to post-NTIA agreements, policies, and oversight mechanisms that already cover
regime. Over the years since the creation of ICANN, the IETF, ICANN, what is needed. This system has worked well without any operational
and IAB have together created a system of agreements, policies, and involvement from the NTIA. Therefore, no new organizaitons or
oversight mechanisms that covers what is needed. structures are needed.
First and foremost, IANA protocol parameters registry updates will
continue to function day-to-day, as they have been doing for the last
decade or more. The IETF community is quite satisfied with the
current arrangement with ICANN. RFC 2860 remains in force and has
served the IETF community very well. RFC 6220 has laid out an
appropriate service description and requirements.
To address issues raised by the IETF community relating to
intellectual property rights, the IAOC is asked to engage the
appropriate parties, both inside and outside the IETF, to make clear
that data in the protocol parameters registries is in the public
domain.
To address a desire by the IETF community to have mechanisms that
allow for additional dispute resolution between the IETF and the
current IANA protocol registries operator, the IAOC is asked to
conclude a supplemental agreement regarding jurisdiction and any
necessary dispute resolution mechanisms that are mutually acceptable
to the parties.
To address concerns regarding appropriate contingencies to transition IANA protocol parameters registry updates will continue to function
to another operator, the IAOC is asked to conclude a supplemental day-to-day, as they have been doing for the last decade or more. The
agreement that- IETF community is quite satisfied with the current arrangement with
ICANN. RFC 2860 remains in force and has served the IETF community
very well. RFC 6220 has laid out an appropriate service description
and requirements.
1. maintains the IANA functions operator's obligations established The protocol parameters registries are in the public domain. It is
under C.7.3 and I.61 of the current IANA functions contract the preference of the IETF community that all relevant parties
between ICANN and the NTIA [NTIA-Contract]; and acknowledge that fact as part of the transition.
2. requires the transfer of any associated marks and identifiers to It is possible in the future that the operation of the protocol
subsequent operators. 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 the protocol parameters registries or other resources
currently located at iana.org.
Discussions during IETF 89 in London led to the following guiding Discussions during IETF 89 in London led to the following guiding
principles for IAB efforts that impact IANA protocol parameter principles for IAB efforts that impact IANA protocol parameter
registries. These principles must be taken together; their order is registries. These principles must be taken together; their order is
not significant. not significant.
1. The IETF protocol parameters registries function has been and 1. The IETF protocol parameters registries function has been and
continues to be capably provided by the Internet technical community. continues to be capably provided by the Internet technical community.
The strength and stability of the function and its foundation within The strength and stability of the function and its foundation within
skipping to change at page 16, line 38 skipping to change at page 16, line 33
in the development of this response. An open mailing list in the development of this response. An open mailing list
(ianaplan@ietf.org) was associated with the working group. In (ianaplan@ietf.org) was associated with the working group. In
addition, IETF's IANA practices have been discussed in the broader addition, IETF's IANA practices have been discussed in the broader
community, and all input is welcome. community, and all input is welcome.
>>> >>>
>>> Links to announcements, agendas, mailing lists, consultations and >>> Links to announcements, agendas, mailing lists, consultations and
>>> meeting proceedings. >>> meeting proceedings.
>>> >>>
IETF Response: [xxx to be completed in more detail] IETF Response:
The following list is not exhaustive, as there have been many open The following list is not exhaustive, as there have been many open
discussions about this transition within the IETF community in the discussions about this transition within the IETF community in the
past few months. past few months.
Creation of an open mailing list to discuss the transition: http://w Creation of an open mailing list to discuss the transition: http://w
ww.ietf.org/mail-archive/web/ietf-announce/current/msg12978.html ww.ietf.org/mail-archive/web/ietf-announce/current/msg12978.html
Announcement of a public session on the transition: http:// Announcement of a public session on the transition: http://
www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html
skipping to change at page 17, line 4 skipping to change at page 16, line 46
discussions about this transition within the IETF community in the discussions about this transition within the IETF community in the
past few months. past few months.
Creation of an open mailing list to discuss the transition: http://w Creation of an open mailing list to discuss the transition: http://w
ww.ietf.org/mail-archive/web/ietf-announce/current/msg12978.html ww.ietf.org/mail-archive/web/ietf-announce/current/msg12978.html
Announcement of a public session on the transition: http:// Announcement of a public session on the transition: http://
www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html
Announcement by the IESG of the intent to form a working group: Announcement by the IESG of the intent to form a working group:
http://www.ietf.org/mail-archive/web/ietf-announce/current/ http://www.ietf.org/mail-archive/web/ietf-announce/current/
msg13170.html msg13170.html
The working group discussion http://www.ietf.org/mail-archive/web/
ianaplan/current/maillist.html
Working group last call http://www.ietf.org/mail-archive/web/
ianaplan/current/msg00760.html
>>> >>>
>>> An assessment of the level of consensus behind your community's >>> An assessment of the level of consensus behind your community's
>>> proposal, including a description of areas of contention or >>> proposal, including a description of areas of contention or
>>> disagreement. >>> disagreement.
>>> >>>
IETF Response: To be completed as the process progresses. IETF Response: To be completed as the process progresses.
3. IANA Considerations 3. IANA Considerations
This memo is a response a request for proposals. No parameter This memo is a response a request for proposals. No parameter
allocations or changes are sought. allocations or changes are sought.
4. Security Considerations 4. Security Considerations
While the IANA framework has shown strong resiliency, the IETF will While the agreement, supplements, policies, and procedures around the
continue to work with all relevant parties to facilitate improvements IANA function have shown strong resiliency, the IETF will continue to
in our standards. work with all relevant parties to facilitate improvements while
maintaining availability of the IANA registries.
5. Acknowledgments 5. IAB Note
This document does not define new processes, and so it seems we This section to be filled in by the IAB.
acknowledge all of the preceding IAB members and members of the
community who developed the processes that we describe. The initial
version of this document was developed collaboratively through both
the IAB IANA Strategy Program and the IETF IANAPLAN WG. Particular
thanks go to Jari Arkko, John Klensin, Andrei Robachevsky, Andrew
Sullivan, Leslie Daigle, Marc Blanchet, Barry Leiba, Brian Carpenter,
Greg Wood, John Curran, Milton Mueller, Alissa Cooper, Andrei
Robachevsky, Miles Fidelman, and Richard Hill.
6. Informative References 6. Acknowledgments
This document describes processes that have been developed by many
members of the community over many years. The initial version of
this document was developed collaboratively through both the IAB IANA
Strategy Program and the IETF IANAPLAN WG. Particular thanks go to
Jari Arkko, John Klensin, Andrei Robachevsky, Andrew Sullivan, Leslie
Daigle, Marc Blanchet, Barry Leiba, Brian Carpenter, Greg Wood, John
Curran, Milton Mueller, Alissa Cooper, Andrei Robachevsky, Miles
Fidelman, Richard Hill, and Suzanne Woolf.
7. Informative References
[METRICS] , "Performance Standards Metrics Report", , [METRICS] , "Performance Standards Metrics Report", ,
<http://www.iana.org/performance/metrics>. <http://www.iana.org/performance/metrics>.
[MOUSUP] , "Supplements to RFC 2860 (the Memorandum of [MOUSUP] , "Supplements to RFC 2860 (the Memorandum of
Understanding between the IETF and ICANN)", , Understanding between the IETF and ICANN)", ,
<http://iaoc.ietf.org/contracts.html>. <http://iaoc.ietf.org/contracts.html>.
[NTIA-Contract] [NTIA-Contract]
, "The NTIA Contract with ICANN", , <http:// , "The NTIA Contract with ICANN", , <http://
skipping to change at page 19, line 38 skipping to change at page 19, line 46
[RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May [RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May
2014. 2014.
[RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC
7282, June 2014. 7282, June 2014.
Appendix A. Changes Appendix A. Changes
NOTE: This section to be removed by RFC Editor at publication. NOTE: This section to be removed by RFC Editor at publication.
A.1. Changes from -01 to -02 A.1. Changes from -02 to -03
o Terminology consistency.
o Add IAB section.
o Changes based on WG discussion on what we prefer as part of the
transition regarding IPR.
o Add discussion about .ARPA domain.
o Elaboration of what registries are involved.
o Additional text around coordination with ICANN.
o Working groups can adopt items within their charters.
o IAB appointments generally last two years.
o Add mention of the Trust.
o Security Considerations update.
A.2. Changes from -01 to -02
o A better description special registries and BGP ASNs. o A better description special registries and BGP ASNs.
o Clarity on how the address space and ASNs are delegated. o Clarity on how the address space and ASNs are delegated.
o Many editorials corrected. o Many editorials corrected.
o Mention of the annual review as part of the SLAs. o Mention of the annual review as part of the SLAs.
o Change about how overlap is presented. o Change about how overlap is presented.
o A number of small wording changes based on feedback. o A number of small wording changes based on feedback.
A.2. Changes from -00 to -01 A.3. Changes from -00 to -01
o Front matter greatly reduced. o Front matter greatly reduced.
o Appendices with charter and RFP added. o Appendices with charter and RFP added.
o Jurisdiction text changed. o Jurisdiction text changed.
o Proposed changes include supplemental agreement(s) to address o Proposed changes include supplemental agreement(s) to address
jurisdiction, dispute resolution, and IPR, including names and jurisdiction, dispute resolution, and IPR, including names and
marks. marks.
 End of changes. 36 change blocks. 
120 lines changed or deleted 172 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/