< draft-ietf-ianaplan-icg-response-05.txt   draft-ietf-ianaplan-icg-response-06.txt >
IANAPLAN E. Lear, Ed. IANAPLAN E. Lear, Ed.
Internet-Draft R. Housley, Ed. Internet-Draft R. Housley, Ed.
Intended status: Informational November 25, 2014 Intended status: Informational November 26, 2014
Expires: May 29, 2015 Expires: May 30, 2015
Draft Response to the Internet Coordination Group Request for Proposals Draft Response to the Internet Coordination Group Request for Proposals
on the IANA protocol parameters registries on the IANA protocol parameters registries
draft-ietf-ianaplan-icg-response-05 draft-ietf-ianaplan-icg-response-06
Abstract Abstract
This document contains the a response to a request for proposals from This document contains the IETF response to a request for proposals
the IANA Stewardship Transition Coordination Group regarding the from 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.
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.
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 May 29, 2015. This Internet-Draft will expire on May 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
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. IAB Note . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5. IAB Note . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
7. Informative References . . . . . . . . . . . . . . . . . . . 18 7. Informative References . . . . . . . . . . . . . . . . . . . 18
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 20
A.1. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 20 A.1. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 20
A.2. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 20 A.2. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 20
A.3. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 20 A.3. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 20
A.4. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 21 A.4. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 20
A.5. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 21 A.5. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 21
A.6. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 21
Appendix B. The Charter of the IANA Stewardship Coordination Appendix B. The Charter of the IANA Stewardship Coordination
Group (ICG . . . . . . . . . . . . . . . . . . . . . 21 Group (ICG . . . . . . . . . . . . . . . . . . . . . 21
Appendix C. IANA Stewardship Transition Coordination Group Appendix C. IANA Stewardship Transition Coordination Group
Request for Proposals . . . . . . . . . . . . . . . 24 Request for Proposals . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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
skipping to change at page 3, line 13 skipping to change at page 3, line 4
(RFP) 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
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 RFP:
In this RFP, "IANA" refers to the functions currently specified in In this RFP, "IANA" refers to the functions currently specified in
the agreement between NTIA and ICANN [http://www.ntia.doc.gov/page/ the agreement between NTIA and ICANN [http://www.ntia.doc.gov/page/
iana-functions-purchase-order] as well as any other functions iana-functions-purchase-order] as well as any other functions
traditionally performed by the IANA functions operator. SAC-067 traditionally performed by the IANA functions operator. SAC-067
[https://www.icann.org/en/system/files/files/sac-067-en.pdf] provides [https://www.icann.org/en/system/files/files/sac-067-en.pdf] provides
one description of the many different meanings of the term "IANA" and one description of the many different meanings of the term "IANA" and
may be useful reading in addition to the documents constituting the may be useful reading in addition to the documents constituting the
agreement itself. agreement itself.
2. The Formal RFP Response 2. The Formal RFP Response
The entire Request for Comments, including introduction, can be found The entire Request for Proposals, including introduction, can be
in Appendix C. found in Appendix C.
>>> >>>
>>> 0. Proposal Type >>> 0. Proposal Type
>>> >>>
>>> Identify which category of the IANA functions this >>> Identify which category of the IANA functions this
>>> submission proposes to address: >>> submission proposes to address:
>>> >>>
IETF Response: IETF Response:
[XXX] Protocol Parameters [XXX] Protocol Parameters
skipping to change at page 4, line 12 skipping to change at page 4, line 6
>>> This section should list the specific, distinct IANA services >>> This section should list the specific, distinct IANA services
>>> or activities your community relies on. For each IANA service >>> or activities your community relies on. For each IANA service
>>> or activity on which your community relies, please provide the >>> or activity on which your community relies, please provide the
>>> following: >>> following:
>>> A description of the service or activity. >>> A description of the service or activity.
>>> >>>
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 primary users
users of the IETF standards and other documents. To ensure of the IETF standards and other documents. To ensure consistent
consistent interpretation of these parameter values by independent 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 any registries containing the parameter values and a pointer to any
associated documentation. The IETF uses the IANA protocol parameters associated documentation. The IETF uses the IANA protocol parameters
registries to store this information in a public location. The IETF registries to store this information in a public location. The IETF
community presently accesses the protocol parameter registries via community presently accesses the protocol parameter registries via
references based on iana.org domain name, and makes use of the term references based on iana.org domain name, and makes use of the term
"IANA" in the protocol parameter registry processes[RFC5226]. "IANA" in the protocol parameter registry processes [RFC5226].
ICANN currently operates the .ARPA top level domain on behalf of the ICANN currently operates the .ARPA top level domain on behalf of the
Internet Architecture Board (IAB). This zone is used for certain Internet Architecture Board (IAB). This zone is used for certain
Internet infrastructure services that are delegated beneath it. We Internet infrastructure services that are delegated beneath it. We
consider .ARPA part of the protocol parameters registries for consider .ARPA part of the protocol parameters registries for
purposes of this response. 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 conformance 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 organization that produces voluntary standards,
to make the Internet work better [RFC3595]. IETF standards are whose goal is to make the Internet work better [RFC3595]. IETF
published in the RFC series. The IETF is responsible for the key standards are published in the RFC series. The IETF is responsible
standards that are used on the Internet today, including IP, TCP, for the key standards that are used on the Internet today, including
DNS, BGP, and HTTP, to name but a few. IP, TCP, DNS, BGP, and HTTP, to name but a few.
The IETF operates in 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
skipping to change at page 5, line 30 skipping to change at page 5, line 20
>>> >>>
>>> 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 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 space and some of its sub-registries, autonomous system number space,
of special use registries with regard to domain names. For more and a number of special use registries with regard to domain names.
detail please refer to the documentation in the "overlaps or For more detail please refer to the documentation in the "overlaps or
interdependencies" section. 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
>>> >>>
skipping to change at page 6, line 17 skipping to change at page 6, line 9
cases, the IETF coordinates with the appropriate organizations. cases, the IETF coordinates with the appropriate organizations.
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 ICANN as the policy authority for the DNS root, including with ICANN as the policy authority for the DNS root, including
community groups that are responsible for ICANN policy on domain community groups that are responsible for ICANN policy on domain
names such as the GNSO and the ccNSO. There are already names such as the Generic Names Supporting Organization (GNSO) and
mechanisms in place to perform this coordination, and the capacity the Country Code Names Supporting Organization (ccNSO). There are
to modify them to meet new conditions as they might already mechanisms in place to perform this coordination, and the
arise.[RFC6761] 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.
those requirements change, we will inform ICANN. [RFC2870] Those requirements are currently under review, in
consultations with the root server community.
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 the IANA protocol address space and AS number space. Through the IANA protocol
parameters registries, the IETF delegates unicast IP address and parameters registries, the IETF delegates unicast IP address and
AS number ranges to the RIR system [RFC7020],[RFC7249]. Special AS number ranges to the RIR system [RFC7020],[RFC7249]. Special
address allocation, such a multicast and anycast addresses, often address allocation, such as multicast and anycast addresses, often
require coordination. Another example of IP addresses that are require coordination. Another example of IP addresses that are
not administered by the RIR system is Unique Local Addresses not administered by the RIR system is Unique Local Addresses
(ULAs) [RFC4193], where local networks employ a prefix that is not (ULAs) [RFC4193], where local networks employ a prefix that is not
intended to be routed on the public Internet. New special address intended to be routed on the public Internet. New special address
allocations are added, from time to time, related to the evolution allocations are added, from time to time, related to the evolution
of the standards. In all cases, these special assignments are of the standards. In all cases, these special assignments are
listed in the IANA protocol paramters 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
skipping to change at page 8, line 4 skipping to change at page 7, line 44
Policy for overall management of the protocol parameters registries Policy for overall management of the protocol parameters registries
is stated in [RFC6220] and [RFC5226]. The first of these documents is stated in [RFC6220] and [RFC5226]. The first of these documents
explains the model for how the registries are to be operated, how explains the model for how the registries are to be operated, how
policy is set, and how oversight takes place. RFC 5226 specifies the policy is set, and how oversight takes place. RFC 5226 specifies the
policies that specification writers may employ when they define new policies that specification writers may employ when they define new
protocol 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, a working group whose scope includes there is sufficient interest, a working group whose scope includes
the proposed work may choose to adopt it, the Internet Engineering the proposed work may choose to adopt it, the IESG may choose to
Steering Group may choose to create a working group, or an Area create a working group, or an Area Director may choose to sponsor the
Director may choose to sponsor the draft. In any case, anyone may draft. In any case, anyone may comment on the proposal as it
comment on the proposal as it progresses. A proposal cannot be progresses. A proposal cannot be passed by the IESG unless it enjoys
passed by the IESG unless it enjoys sufficient community support as sufficient community support as to indicate rough consensus
to indicate rough consensus [RFC7282]. In each case, a "Last Call" [RFC7282]. In each case, a "Last Call" is made so that there is
is made so that there is notice of any proposed change to a policy or notice of any proposed change to a policy or process. Anyone may
process. Anyone may comment during a Last Call. For example, this comment during a Last Call. For example, this process is currently
process is currently being used to update RFC 5226 being used to update RFC 5226 [I-D.leiba-cotton-iana-5226bis].
[I-D.leiba-cotton-iana-5226bis].
>>> >>>
>>> 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
skipping to change at page 9, line 36 skipping to change at page 9, line 29
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 operator on approve the appointment of an organization to act as IANA operator on
behalf of the IETF. The IAB is also responsible for establishing behalf of the IETF. The IAB is also responsible for establishing
liaison relationships with other orgnaizations on behalf of the IETF. liaison relationships with other organizations on behalf of the IETF.
The 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. The active members are
sent to the Internet Society Board of Trustees for confirmation. In chosen randomly from volunteers with a history of participation in
general, members are appointed for terms of two years. The IAB the IETF, with limits regarding having too many active members with
selects its own chair. the same affiliation. The selection of the active members is
performed in a manner that makes it possible for anyone to verify
that the correct procedure was followed. The slate of candidates
selected by the active members are sent to the Internet Society Board
of Trustees for confirmation. In 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 10, line 37 skipping to change at page 10, line 34
the MoU. 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. The Administrative Oversight Committee (IAOC) oversees the IAD. The
members of the IAOC are also the trustees of the IETF Trust, whose members of the IAOC are also the trustees of the IETF Trust, whose
main purpose is to hold certain intellectual property for the benefit main purpose is to hold certain intellectual property for the benefit
of the IETF as a whole. IAOC members are appointed by the Internet of the IETF as a whole. IAOC members are appointed by the Internet
Society Board of Trustees, the IAB, the IESG, and the NOMCOM Society Board of Trustees, the IAB, the IESG, and the NOMCOM
[RFC4071]. The IAOC works with the IANA functions operator to [RFC4071]. The IAOC works with the IANA functions operator to
establish annual IANA performance metrics[METRICS] and operational establish annual IANA performance metrics [METRICS] and operational
procedures, and the resulting document is adopted as an supplement to procedures, and the resulting document is adopted as an supplement to
the MoU each year [MOUSUP]. In accordance with these supplements, an the MoU each year [MOUSUP]. Starting from 2014, in accordance with
annual review is performed to ensure that protocol parameter requests these supplements, an annual audit is performed to ensure that
are being processed according to the established policies. protocol parameter requests are being processed according to the
established policies. The conclusions of this audit will be
available for anyone in the world to review.
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 12, line 25 skipping to change at page 12, line 18
o The protocol parameters registries are in the public domain. It o The protocol parameters registries are in the public domain. It
is the preference of the IETF community that all relevant parties is the preference of the IETF community that all relevant parties
acknowledge that fact as part of the transition. acknowledge that fact as part of the transition.
o It is possible in the future that the operation of the protocol o It is possible in the future that the operation of the protocol
parameters registries may be transitioned from ICANN to subsequent parameters registries may be transitioned from ICANN to subsequent
operator(s). It is the preference of the IETF community that, as operator(s). It is the preference of the IETF community that, as
part of the NTIA transition, ICANN acknowledge that it will carry part of the NTIA transition, ICANN acknowledge that it will carry
out the obligations established under C.7.3 and I.61 of the out the obligations established under C.7.3 and I.61 of the
current IANA functions contract between ICANN and the current IANA functions contract between ICANN and the NTIA
NTIA[NTIA-Contract] to achieve a smooth transition to subsequent [NTIA-Contract] to achieve a smooth transition to subsequent
operator(s), should the need arise. Furthermore, in the event of operator(s), should the need arise. Furthermore, in the event of
a transition it is the expectation of the IETF community that a transition it is the expectation of the IETF community that
ICANN, the IETF, and subsequent operator(s) will work together to ICANN, the IETF, and subsequent operator(s) will work together to
minimize disruption in the use the protocol parameters registries minimize disruption in the use the protocol parameters registries
or other resources currently located at iana.org. or other resources currently located at iana.org.
Discussions during IETF 89 in London led to the following guiding Discussions during the IETF 89 meeting in London led to the following
principles for IAB efforts that impact IANA protocol parameter guiding principles for IAB efforts that impact IANA protocol
registries. These principles must be taken together; their order is parameter registries. These principles must be taken together; their
not significant. order is 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
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 parameters We think the structures that sustain the protocol parameters
registries function needs to be strong enough that they can be registries function need to be strong enough that they can be offered
offered independently by the Internet technical community, without independently by the Internet technical community, without the need
the need for backing from external parties. And we believe we for backing from external parties. And we believe we largely are
largely are there already, although the system can be strengthened there already, although the system can be strengthened further, and
further, and continuous improvements are being made. continuous improvements are being made.
2. The protocol parameters registries 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 parameters function accountable for following those the protocol parameters function accountable for following those
skipping to change at page 19, line 9 skipping to change at page 19, line 5
Procedures", BCP 25, RFC 2418, September 1998. Procedures", BCP 25, RFC 2418, September 1998.
[RFC2850] Internet Architecture Board and B. Carpenter, "Charter of [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of
the Internet Architecture Board (IAB)", BCP 39, RFC 2850, the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
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.
[RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root
Name Server Operational Requirements", BCP 40, RFC 2870,
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 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002. 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.
skipping to change at page 20, line 22 skipping to change at page 20, line 22
[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 -04 to -05 A.1. Changes from -05 to -06
o Inclusion of agreed substantial comments from the AD.
o Editorial changes.
A.2. Changes from -04 to -05
o Change to simpler text for answer about stability and security. o Change to simpler text for answer about stability and security.
o Mention of RFC 5226bis. o Mention of RFC 5226bis.
A.2. Changes from -03 to -04 A.3. Changes from -03 to -04
o Additional text regarding what is needed in Section III. o Additional text regarding what is needed in Section III.
o Appropriate language modifications in section IV to match the o Appropriate language modifications in section IV to match the
above changes in III. above changes in III.
o Acknowledgments edits. o Acknowledgments edits.
A.3. Changes from -02 to -03 A.4. Changes from -02 to -03
o Terminology consistency. o Terminology consistency.
o Add IAB section. o Add IAB section.
o Changes based on WG discussion on what we prefer as part of the o Changes based on WG discussion on what we prefer as part of the
transition regarding IPR. transition regarding IPR.
o Add discussion about .ARPA domain. o Add discussion about .ARPA domain.
skipping to change at page 21, line 11 skipping to change at page 21, line 17
o Additional text around coordination with ICANN. o Additional text around coordination with ICANN.
o Working groups can adopt items within their charters. o Working groups can adopt items within their charters.
o IAB appointments generally last two years. o IAB appointments generally last two years.
o Add mention of the Trust. o Add mention of the Trust.
o Security Considerations update. o Security Considerations update.
A.4. Changes from -01 to -02 A.5. 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.5. Changes from -00 to -01 A.6. 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. 32 change blocks. 
72 lines changed or deleted 92 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/