< draft-ietf-ianaplan-icg-response-01.txt   draft-ietf-ianaplan-icg-response-02.txt >
IANAPLAN E. Lear, Ed. IANAPLAN E. Lear, Ed.
Internet-Draft R. Housley, Ed. Internet-Draft R. Housley, Ed.
Intended status: Informational October 16, 2014 Intended status: Informational October 27, 2014
Expires: April 19, 2015 Expires: April 30, 2015
Draft Response to the Internet Coordination Group Request for Proposals Draft Response to the Internet Coordination Group Request for Proposals
on IANA on IANA
draft-ietf-ianaplan-icg-response-01 draft-ietf-ianaplan-icg-response-02
Abstract Abstract
This document contains the a draft response to a request for This document contains the a response to a request for proposals from
proposals from the IANA Stewardship Transition Coordination Group the IANA Stewardship Transition Coordination Group regarding the
regarding the protocol parameters registries. It is meant to be protocol parameters registries. It is meant to be included in an
included in an aggregate proposal that also includes contributions aggregate proposal that also includes contributions covering domain
covering names and addresses 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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 19, 2015. This Internet-Draft will expire on April 30, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . . . . . . . . . . . . . . . 16 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
6. Informative References . . . . . . . . . . . . . . . . . . . 16 6. Informative References . . . . . . . . . . . . . . . . . . . 17
Appendix A. Changes since -00 . . . . . . . . . . . . . . . . . 18 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 19
A.1. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 19
A.2. 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 . . . . . . . . . . . . . . . . . . . . . 18 Group (ICG . . . . . . . . . . . . . . . . . . . . . 20
Appendix C. IANA Stewardship Transition Coordination Group Appendix C. IANA Stewardship Transition Coordination Group
Request for Proposals . . . . . . . . . . . . . . . 21 Request for Proposals . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 the
respective functions that IANA performs, in order that they may put respective functions that IANA performs, in order that they may put
forth a proposal to the NTIA. The final request for proposal (RFP) forth a proposal to the NTIA. The final request for proposal (RFP)
can be found in Appendix C. 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
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
asked in order to match the RFC format. asked in order to match the RFC format.
As if to demonstrate the last point, the following text was included As if to demonstrate the last point, the following text was included
in a footnote in the original propsoal. in a footnote in the original propsoal.
skipping to change at page 4, line 4 skipping to change at page 4, line 4
>>> >>>
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
registry containing the parameter values and a pointer to registries containing the parameter values and a pointer to
documentation of the associated semantic intent. The IETF uses the documentation of the associated semantic intent. The IETF uses the
IANA protocol parameter registries to implement such registries. IANA protocol parameters registries to store this information in a
public location.
>>> >>>
>>> 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 parameter registry operator maintains the protocol The IANA protocol parameters registries operator maintains the
parameters registry for the IETF in accordance with all relevant IETF protocol parameters registries for the IETF in accordance with all
policies, in accordance with the Memorandum of Understanding and relevant IETF policies, in accordance with the Memorandum of
assoicated supplemental agreements that include service level Understanding[RFC2860] and associated supplemental agreements that
agreements (SLAs). include service level agreements (SLAs) established between the IETF
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.
The IETF operates an open and transparent manner [RFC6852]. The The IETF operates in an open and transparent manner [RFC6852]. The
processes that govern the IETF are also published in the RFC series. processes that govern the IETF are also published in the RFC series.
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),
skipping to change at page 5, line 5 skipping to change at page 5, line 5
propose a change during a Last Call, and anyone may participate in propose a change during a Last Call, and anyone may participate in
the community discussion. 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 parameter registries are the product of IETF work. The protocol parameters registries are the product of IETF work.
Administration of the protocol parameter registries is the service Administration of the protocol parameters registries is the service
that is provide 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. This is the case with both names and numbers, as organizations. In this sense, there is no overlap between
described in the paragraphs below. In all cases, the IETF engages organizations because responsibility for each registry is carefully
directly with the appropriate organizations to ensure that each delineated. There are, however, points of interaction between other
organization's policies are followed. organizations, and a few cases where we may further define the scope
of a registry for technical purposes. This is the case with both
names and numbers, as described in the paragraphs below. In all
cases, the IETF engages directly 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, including anyone from ICANN or the regional Internet participate. Staff and participants from ICANN or the Regional
registries (RIRs), and many people from those organizations regularly Internet Registries (RIRs) regularly participate in IETF activities.
do.
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 the Generic Names Support Organization (GNSO). We already
perform this coordination.[RFC6761] perform this coordination.[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. We will continue to been and will be updates to that protocol. As we make changes we
coordinate with ICANN regarding those changes. will broadly consult the operational community about the impact of
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 has established registries with IANA for special IPv4 and o The IETF is responsible for policy relating to the entire IP
IPv6 assignments. These are specified in [RFC6890]. The IETF address space and AS number space. Through IANA, the IETF
coordinates such assignments with the RIRs. delegates unicast IP address and AS number ranges to the RIR
system [RFC7020],[RFC7249]. Special address allocation, such a
multicast and anycast addresses, often require coordination.
Another example of IP addresses that are not administered by the
RIR system is Unique Local Addresses (ULAs) [RFC4193], where local
networks employ a prefix that is not intended to be routed on the
public Internet. New special address allocations are added, from
time to time, related to the evolution of the standards. In all
cases, these special assignments are listed in the IANA
registries.
o The IETF maintains sub-registries for special IPv4 and IPv6
assignments. These are specified in [RFC3307], [RFC5771], and
[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 expansion of the BGP service providers. A recent example is the extensions to BGP to
community field from 16 to 32 bits.[RFC6793] It is important to carry the Autonomous System numbers as four-octet entities
note that this change occurred out of operational necessity, and [RFC6793]. It is important to note that this change occurred out
it demonstrated strong alignment between the RIRs and the IETF. of operational necessity, and it demonstrated strong alignment
between the RIRs and the IETF.
>>> II. Existing, Pre-Transition Arrangements >>> II. Existing, Pre-Transition Arrangements
>>> >>>
>>> This section should describe how existing IANA-related >>> This section should describe how existing IANA-related
>>> arrangements work, prior to the transition. >>> arrangements work, prior to the transition.
>>> >>>
>>> A. Policy Sources >>> A. Policy Sources
>>> >>>
>>> >>>
skipping to change at page 6, line 32 skipping to change at page 6, line 50
>>> conduct of the services or activities described above. If there >>> conduct of the services or activities described above. If there
>>> are distinct sources of policy or policy development for >>> are distinct sources of policy or policy development for
>>> different IANA activities, then please describe these >>> different IANA activities, then please describe these
>>> separately. For each source of policy or policy development, >>> separately. For each source of policy or policy development,
>>> please provide the following: >>> please provide the following:
>>> >>>
>>> 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 registry. 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 RFCs in Policy for overall management of the registries is stated in
[RFC6220] and [RFC5226]. The first of these documents explains the [RFC6220] and [RFC5226]. The first of these documents explains the
model for how the registries are to be operated, how policy is set, model for how the registries are to be operated, how policy is set,
and how oversight takes place. RFC 5226 specifies the policies that and how oversight takes place. RFC 5226 specifies the policies that
specification writers may employ when they define new protocol specification writers may employ when they define new protocol
registries in the "IANA Considerations" section of each 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, the Internet Engineering Steering Group
may choose to create a working group or an Area Director may choose may choose to create a working group or an Area Director may choose
to sponsor the draft. In either case, anyone may comment on the to sponsor the draft. In either case, anyone may comment on the
proposal as it progresses. A proposal cannot be passed by the IESG proposal as it progresses. A proposal cannot be passed by the IESG
unless it enjoys sufficient community support as to indicate rough unless it enjoys sufficient community support as to indicate rough
consensus [RFC7282] In each case, a "Last Call" is made so that consensus [RFC7282]. In each case, a "Last Call" is made so that
there is notice of any proposed change to a policy or process. there is notice of any proposed change to a policy or process.
Anyone may comment during a Last Call. 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 an someone claims appropriate remedy is applied. In the case where someone claims that
that the procedures themselves are insufficient or inadequate in some the procedures themselves are insufficient or inadequate in some way
way to address a circumstance, one may appeal an IAB decision to the to address a circumstance, one may appeal an IAB decision to the
Internet Society Board of Trustees. Internet Society Board of Trustees.
>>> >>>
>>> References to documentation of policy development and dispute >>> References to documentation of policy development and dispute
>>> resolution processes. >>> resolution processes.
>>> >>>
IETF Response: As mentioned above, [RFC2026] Section 6.5 specifies a IETF Response: As mentioned above, [RFC2026] Section 6.5 specifies a
conflict resolution and appeals process. [RFC2418] specifies working conflict resolution and appeals process. [RFC2418] specifies working
group procedures. Note that both of these documents have been group procedures. Note that both of these documents have been
amended in later RFCs as indicated in the [RFC-INDEX]. Please also amended in later RFCs as indicated in the [RFC-INDEX]. Please also
see the references at the bottom of this document. see the references at the bottom of this document.
>>> >>>
>>> B. Oversight and Accountability >>> B. Oversight and Accountability
>>> >>>
>>> This section should describe all the ways in which oversight is >>> This section should describe all the ways in which oversight is
skipping to change at page 8, line 15 skipping to change at page 8, line 33
>>> >>>
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 have been specified in II.A. 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
skipping to change at page 8, line 42 skipping to change at page 9, line 15
relationships with other orgnaizations on behalf of the IETF. The relationships with other orgnaizations on behalf of the IETF. The
IAB's charter is to be found in [RFC2850]. 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 serve for two years. The IAB selects its own chair.
The IAB provides oversight of the protocol parameter 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.
>>> >>>
>>> 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
skipping to change at page 9, line 27 skipping to change at page 10, line 9
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 staff for the IETF and the Internet Research Task Force (IRTF), a
peer organization to the IETF that focuses on research. Each year a peer organization to the IETF that focuses on research. Each year a
service level agreement is negotiated that supplements the MoU. 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. IAOC
members are appointed by the Internet Society Board of Trustees, the members are appointed by the Internet Society Board of Trustees, the
IAB, the IESG, and the NOMCOM [RFC4071]. The IAOC works with ICANN IAB, the IESG, and the NOMCOM [RFC4071]. The IAOC works with the
to establish annual IANA performance metrics and operational IANA functions operator to establish annual IANA performance metrics
procedures, and the resulting document is adopted as an supplement to and operational procedures, and the resulting document is adopted as
the MoU each year [MOUSUP]. an supplement to the MoU 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 10, line 25 skipping to change at page 11, line 10
>>> 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 changes are required, as over the years since the creation of No major changes are required, however, the IETF community has
ICANN, the IETF, ICANN, and IAB have together created a system of expressed a desire for several points to be addressed by supplemental
agreements, policies, and oversight mechanisms that covers what is agreements to the IETF-ICANN MoU, prior to a transition to post-NTIA
needed. regime. Over the years since the creation of ICANN, the IETF, ICANN,
and IAB have together created a system of agreements, policies, and
oversight mechanisms that covers what is needed.
First and foremost, IANA protocol parameter registry updates will First and foremost, IANA protocol parameters registry updates will
continue to function day-to-day, as they have been doing for the last 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 decade or more. The IETF community is quite satisfied with the
current arrangement with ICANN. RFC 2860 remains in force and has current arrangement with ICANN. RFC 2860 remains in force and has
served the IETF community very well. RFC 6220 has laid out an served the IETF community very well. RFC 6220 has laid out an
appropriate service description and requirements. appropriate service description and requirements.
To address issues raised by the IETF community relating to To address issues raised by the IETF community relating to
intellectual property rights; the IAOC is asked to engage the intellectual property rights, the IAOC is asked to engage the
appropriate parties, both inside and outside the IETF, to make clear appropriate parties, both inside and outside the IETF, to make clear
that data in the protocol parameters registries is in the public that data in the protocol parameters registries is in the public
domain. domain.
To address a desire by some members of the IETF community to have To address a desire by the IETF community to have mechanisms that
mechanisms that allow for additional dispute resolution between the allow for additional dispute resolution between the IETF and the
IETF and the current IANA protocol registries operator, the IAOC is current IANA protocol registries operator, the IAOC is asked to
asked to conclude a supplemental agreement regarding jurisdiction and conclude a supplemental agreement regarding jurisdiction and any
any necessary dispute resolution mechanisms that are mutually necessary dispute resolution mechanisms that are mutually acceptable
acceptable to the parties. to the parties.
To address concerns regarding appropriate contingencies to transition To address concerns regarding appropriate contingencies to transition
to another operator, IAOC is asked to conclude a supplemental to another operator, the IAOC is asked to conclude a supplemental
agreement that- agreement that-
1. captures provisions C.7.3 and I.61 of the current IANA functions 1. maintains the IANA functions operator's obligations established
contract between ICANN and the NTIA [NTIA-Contract]; and under C.7.3 and I.61 of the current IANA functions contract
between ICANN and the NTIA [NTIA-Contract]; and
2. requires the transfer of any associated marks and identifiers to 2. requires the transfer of any associated marks and identifiers to
a subsequent operator. subsequent operators.
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 parameter registry 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
the Internet technical community are both important given how the Internet technical community are both important given how
critical protocol parameters are to the proper functioning of IETF critical protocol parameters are to the proper functioning of IETF
protocols. protocols.
We think the structures that sustain the protocol parameter registry We think the structures that sustain the protocol parameters
function needs to be strong enough that they can be offered registries function needs to be strong enough that they can be
independently by the Internet technical community, without the need offered independently by the Internet technical community, without
for backing from external parties. And we believe we largely are the need for backing from external parties. And we believe we
there already, although the system can be strengthened further, and largely are there already, although the system can be strengthened
continuous improvements are being made. further, and continuous improvements are being made.
2. The protocol parameter registry function requires openness, 2. The protocol parameters registries function requires openness,
transparency, and accountability. transparency, and accountability.
Existing documentation of how the function is administered and Existing documentation of how the function is administered and
overseen is good [RFC2860], [RFC6220]. Further articulation and overseen is good [RFC2860], [RFC6220]. Further articulation and
clarity may be beneficial. It is important that the whole Internet clarity may be beneficial. It is important that the whole Internet
community can understand how the function works, and that the community can understand how the function works, and that the
processes for registering parameters and holding those who oversee processes for registering parameters and holding those who oversee
the protocol parameter function accountable for following those the protocol parameters function accountable for following those
processes are understood by all interested parties. We are committed processes are understood by all interested parties. We are committed
to making improvements here if necessary. to making improvements here if necessary.
3. Any contemplated changes to the protocol parameter registry 3. Any contemplated changes to the protocol parameters registries
function should respect existing Internet community agreements. function should respect existing Internet community agreements.
The protocol parameter registry is working well. The existing The protocol parameters registries function is working well. The
Memorandum of Understanding in RFC 2860 defines "the technical work existing Memorandum of Understanding in RFC 2860 defines "the
to be carried out by the Internet Assigned Numbers Authority on technical work to be carried out by the Internet Assigned Numbers
behalf of the Internet Engineering Task Force and the Internet Authority on behalf of the Internet Engineering Task Force and the
Research Task Force." Any modifications to the protocol parameter Internet Research Task Force." Any modifications to the protocol
registry function should be made using the IETF process to update RFC parameters registries function should be made using the IETF process
6220 and other relevant RFCs. Put quite simply: evolution, not to update RFC 6220 and other relevant RFCs. Put quite simply:
revolution. evolution, not revolution.
4. The Internet architecture requires and receives capable service 4. The Internet architecture requires and receives capable service
by Internet registries. by Internet registries.
The stability of the Internet depends on capable provision of not The stability of the Internet depends on capable provision of not
just IETF protocol parameters, but IP numbers, domain names, and just IETF protocol parameters, but IP numbers, domain names, and
other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined
protocols. Thus we expect the role of the IETF in standards protocols. Thus we expect the role of the IETF in standards
development, architectural guidance, and allocation of certain name/ development, architectural guidance, and allocation of certain name/
number parameters to continue. IP multicast addresses and special- number parameters to continue. IP multicast addresses and special-
skipping to change at page 12, line 41 skipping to change at page 13, line 33
protocols. The IAB, on behalf of the IETF, has the responsibility to protocols. The IAB, on behalf of the IETF, has the responsibility to
define and manage the relationship with the protocol registry define and manage the relationship with the protocol registry
operator role. This responsibility includes the selection and operator role. This responsibility includes the selection and
management of the protocol parameter registry operator, as well as management of the protocol parameter registry operator, as well as
management of the parameter registration process and the guidelines management of the parameter registration process and the guidelines
for parameter allocation. for parameter allocation.
6. The protocol parameters registries are provided as a public 6. The protocol parameters registries are provided as a public
service. service.
Directions for the creation of protocol parameter registries and the Directions for the creation of protocol parameters registries and the
policies for subsequent additions and updates are specified in RFCs. policies for subsequent additions and updates are specified in RFCs.
The protocol parameters registries are available to everyone, and The protocol parameters registries are available to everyone, and
they are published in a form that allows their contents to be they are published in a form that allows their contents to be
included in other works without further permission. These works included in other works without further permission. These works
include, but are not limited to, implementations of Internet include, but are not limited to, implementations of Internet
protocols and their associated documentation. protocols and their associated documentation.
These principles will guide the IAB, IAOC, and the rest of the IETF These principles will guide the IAB, IAOC, and the rest of the IETF
community as they work with ICANN to establish future IANA community as they work with ICANN to establish future IANA
performance metrics and operational procedures. performance metrics and operational procedures.
skipping to change at page 13, line 32 skipping to change at page 14, line 23
>>> arrangements. >>> arrangements.
>>> >>>
IETF Response: IETF Response:
No structural changes are required. The principles listed above will No structural changes are required. The principles listed above will
guide IAB, IAOC, and the rest of the IETF community as they work with guide IAB, IAOC, and the rest of the IETF community as they work with
ICANN to establish future IANA performance metrics and operational ICANN to establish future IANA performance metrics and operational
procedures, as they have in the past. procedures, as they have in the past.
As no services are expected to change, no continuity issuees are As no services are expected to change, no continuity issues are
anticipated, and there are no new technical or operational methods anticipated, and there are no new technical or operational methods
proposed by the IETF to test. The IETF leadership, ICANN, and the proposed by the IETF to test. The IETF leadership, ICANN, and the
RIRs maintain an ongoing informal dialog to spot any unforeseen RIRs maintain an ongoing informal dialog to spot any unforeseen
issues that might arise as a result of other changes. issues that might arise as a result of other changes.
What is necessary as part of transition is the completion of What is necessary as part of transition is the completion of
supplemental agreement(s) discussed in the previous section of this supplemental agreement(s) discussed in the previous section of this
RFP. RFP.
>>> >>>
skipping to change at page 14, line 36 skipping to change at page 15, line 28
protected by maintaining the current service in its current form. protected by maintaining the current service in its current form.
>>> >>>
>>> "Meet the needs and expectation of the global customers and >>> "Meet the needs and expectation of the global customers and
>>> partners of the IANA services;" >>> partners of the IANA services;"
>>> >>>
IETF Response: IETF Response:
Implementers and their users from around the world make use of the Implementers and their users from around the world make use of the
IETF standards and the associated IANA protocol parameter registries. IETF standards and the associated IANA protocol parameters
The current IANA protocol parameter registry system is meeting the registries. The current IANA protocol parameters registries system
needs of these global customers. This proposal continues to meet is meeting the needs of these global customers. This proposal
their needs by maintaining the existing processes that have served continues to meet their needs by maintaining the existing processes
them well in the past. that have served them well in the past.
>>> >>>
>>> >>>
>>> "Maintain the openness of the Internet." >>> "Maintain the openness of the Internet."
>>> >>>
IETF Response: IETF Response:
This proposal maintains the existing open framework that allows This proposal maintains the existing open framework that allows
anyone to participate in the development of IETF standards, including anyone to participate in the development of IETF standards, including
the IANA protocol parameter registry policies. Further, an the IANA protocol parameters registries policies. Further, an
implementer anywhere in the world has full access to the protocol implementer anywhere in the world has full access to the protocol
specification published in the RFC series and the protocol parameter specification published in the RFC series and the protocol parameters
registries published at iana.org. Those who require assignments in registries published at iana.org. Those who require assignments in
the IANA protocol registries will continue to be able to do so, as the IANA protocol registries will continue to be able to do so, as
specified by the existing policies for those registries. specified by the existing policies for those registries.
{We will have an open discussion, make changes based on that
discussion, and then conduct a Last Call to confirm that there is
rough consensus for the proposal.}
>>> >>>
>>> VI. Community Process >>> VI. Community Process
>>> >>>
>>> This section should describe the process your community used for >>> This section should describe the process your community used for
>>> developing this proposal, including: >>> developing this proposal, including:
>>> >>>
>>> o The steps that were taken to develop the proposal and to >>> o The steps that were taken to develop the proposal and to
>>> determine consensus. >>> determine consensus.
>>> >>>
skipping to change at page 16, line 39 skipping to change at page 17, line 35
in our standards. in our standards.
5. Acknowledgments 5. Acknowledgments
This document does not define new processes, and so it seems we This document does not define new processes, and so it seems we
acknowledge all of the preceding IAB members and members of the acknowledge all of the preceding IAB members and members of the
community who developed the processes that we describe. The initial community who developed the processes that we describe. The initial
version of this document was developed collaboratively through both version of this document was developed collaboratively through both
the IAB IANA Strategy Program and the IETF IANAPLAN WG. Particular the IAB IANA Strategy Program and the IETF IANAPLAN WG. Particular
thanks go to Jari Arkko, John Klensin, Andrei Robachevsky, Andrew thanks go to Jari Arkko, John Klensin, Andrei Robachevsky, Andrew
Sullivan, Leslie Daigle, Barry Leiba, Brian Carpenter, Greg Wood, Sullivan, Leslie Daigle, Marc Blanchet, Barry Leiba, Brian Carpenter,
John Curran, and Milton Mueller. Greg Wood, John Curran, Milton Mueller, Alissa Cooper, Andrei
Robachevsky, Miles Fidelman, and Richard Hill.
6. Informative References 6. 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>.
skipping to change at page 17, line 30 skipping to change at page 18, line 27
May 2000. May 2000.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, June 2000. Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC3172] Huston, G., "Management Guidelines & Operational [RFC3172] Huston, G., "Management Guidelines & Operational
Requirements for the Address and Routing Parameter Area Requirements for the Address and Routing Parameter Area
Domain ("arpa")", BCP 52, RFC 3172, September 2001. Domain ("arpa")", BCP 52, RFC 3172, September 2001.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", RFC [RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", RFC
3595, September 2003. 3595, September 2003.
[RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and
Recall Process: Operation of the Nominating and Recall Recall Process: Operation of the Nominating and Recall
Committees", BCP 10, RFC 3777, June 2004. Committees", BCP 10, RFC 3777, June 2004.
[RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF
Administrative Support Activity (IASA)", BCP 101, RFC Administrative Support Activity (IASA)", BCP 101, RFC
4071, April 2005. 4071, April 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
March 2010.
[RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G., [RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G.,
Internet Architecture Board, "Defining the Role and Internet Architecture Board, "Defining the Role and
Function of IETF Protocol Parameter Registry Operators", Function of IETF Protocol Parameter Registry Operators",
RFC 6220, April 2011. RFC 6220, April 2011.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, February 2013. RFC 6761, February 2013.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793, December Autonomous System (AS) Number Space", RFC 6793, December
2012. 2012.
[RFC6852] Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St. [RFC6852] Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St.
Amour, "Affirmation of the Modern Paradigm for Standards", Amour, "Affirmation of the Modern Paradigm for Standards",
RFC 6852, January 2013. RFC 6852, January 2013.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153, RFC "Special-Purpose IP Address Registries", BCP 153, RFC
6890, April 2013. 6890, April 2013.
[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The
Internet Numbers Registry System", RFC 7020, August 2013.
[RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May
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 since -00 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
o A better description special registries and BGP ASNs.
o Clarity on how the address space and ASNs are delegated.
o Many editorials corrected.
o Mention of the annual review as part of the SLAs.
o Change about how overlap is presented.
o A number of small wording changes based on feedback.
A.2. 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. 52 change blocks. 
108 lines changed or deleted 164 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/