< draft-ietf-ianaplan-icg-response-04.txt   draft-ietf-ianaplan-icg-response-05.txt >
IANAPLAN E. Lear, Ed. IANAPLAN E. Lear, Ed.
Internet-Draft R. Housley, Ed. Internet-Draft R. Housley, Ed.
Intended status: Informational November 21, 2014 Intended status: Informational November 25, 2014
Expires: May 25, 2015 Expires: May 29, 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-04 draft-ietf-ianaplan-icg-response-05
Abstract Abstract
This document contains the a response to a request for proposals from This document contains the a response to a request for proposals from
the IANA Stewardship Transition Coordination Group regarding the the IANA Stewardship Transition Coordination Group regarding the
protocol parameters registries. It is meant to be included in an protocol parameters registries. It is meant to be included in an
aggregate proposal that also includes contributions covering domain aggregate proposal that also includes contributions covering domain
names and numbering resources that will be submitted from their names and numbering resources that will be submitted from their
respective operational communities. The IETF community is invited to respective operational communities. The IETF community is invited to
comment and propose changes to this document. comment and propose changes to this document.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 25, 2015. This Internet-Draft will expire on May 29, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. IAB Note . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
7. Informative References . . . . . . . . . . . . . . . . . . . 17 7. Informative References . . . . . . . . . . . . . . . . . . . 18
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 20
A.1. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 19 A.1. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 20
A.2. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 20 A.2. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 20
A.3. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 20 A.3. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 20
A.4. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 20 A.4. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 21
A.5. 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 . . . . . . . . . . . . . . . . . . . . . . . 29 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
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
skipping to change at page 7, line 46 skipping to change at page 8, line 11
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 Internet Engineering
Steering Group may choose to create a working group, or an Area Steering Group may choose to create a working group, or an Area
Director may choose to sponsor the draft. In any case, anyone may Director may choose to sponsor the draft. In any case, anyone may
comment on the proposal as it progresses. A proposal cannot be comment on the proposal as it progresses. A proposal cannot be
passed by the IESG unless it enjoys sufficient community support as passed by the IESG unless it enjoys sufficient community support as
to indicate rough consensus [RFC7282]. In each case, a "Last Call" to indicate rough consensus [RFC7282]. In each case, a "Last Call"
is made so that there is notice of any proposed change to a policy or is made so that there is notice of any proposed change to a policy or
process. Anyone may comment during a Last Call. process. Anyone may comment during a Last Call. For example, this
process is currently being used to update RFC 5226
[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
resolution and appeals process that includes the responsible Area resolution and appeals process that includes the responsible Area
Director, the IESG, and the IAB. Should appeals be upheld, an Director, the IESG, and the IAB. Should appeals be upheld, an
appropriate remedy is applied. In the case where someone claims that appropriate remedy is applied. In the case where someone claims that
skipping to change at page 10, line 4 skipping to change at page 10, line 17
that special treatment is needed, the operator for registries is that special treatment is needed, the operator for registries is
currently ICANN. currently ICANN.
>>> >>>
>>> A description of the mechanism (e.g., contract, reporting >>> A description of the mechanism (e.g., contract, reporting
>>> scheme, auditing scheme, etc.). This should include a >>> scheme, auditing scheme, etc.). This should include a
>>> description of the consequences of the IANA functions operator >>> description of the consequences of the IANA functions operator
>>> not meeting the standards established by the mechanism, the >>> not meeting the standards established by the mechanism, the
>>> extent to which the output of the mechanism is transparent and >>> extent to which the output of the mechanism is transparent and
>>> the terms under which the mechanism may change. >>> the terms under which the mechanism may change.
>>> >>>
IETF Response: IETF Response:
A memorandum of understanding (MoU) between ICANN and the IETF A memorandum of understanding (MoU) between ICANN and the IETF
community has been in place since 2000. It can be found in community has been in place since 2000. It can be found in
[RFC2860]. The MoU defines the work to be carried out by the IANA [RFC2860]. The MoU defines the work to be carried out by the IANA
functions operator for the IETF and the Internet Research Task Force functions operator for the IETF and the Internet Research Task Force
(IRTF), a peer organization to the IETF that focuses on research. (IRTF), a peer organization to the IETF that focuses on research.
Each year a service level agreement is negotiated that supplements Each year a service level agreement is negotiated that supplements
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 and operational procedures, establish annual IANA performance metrics[METRICS] and operational
and the resulting document is adopted as an supplement to the MoU procedures, and the resulting document is adopted as an supplement to
each year [MOUSUP]. In accordance with these supplements, an annual the MoU each year [MOUSUP]. In accordance with these supplements, an
review is performed to ensure that protocol parameter requests are annual review is performed to ensure that protocol parameter requests
being processed according to the established policies. 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 15, line 4 skipping to change at page 15, line 23
outlined in our response in Section III of this RFP. outlined in our response in Section III of this RFP.
>>> >>>
>>> V. NTIA Requirements >>> V. NTIA Requirements
>>> >>>
>>> Additionally, NTIA has established that the transition proposal >>> Additionally, NTIA has established that the transition proposal
>>> must meet the following five requirements: >>> must meet the following five requirements:
>>> >>>
>>> "Support and enhance the multistakeholder model;" >>> "Support and enhance the multistakeholder model;"
>>> >>>
IETF Response: IETF Response:
Everyone is welcome to participate in IETF activities. The policies Everyone is welcome to participate in IETF activities. The policies
and procedures are outlined in the documents we named above. In- and procedures are outlined in the documents we named above. In-
person attendance is not required for participation, and many people person attendance is not required for participation, and many people
participate in email discussions that have never attended an IETF participate in email discussions that have never attended an IETF
meeting. An email account is the only requirement to participate. meeting. An email account is the only requirement to participate.
The IETF makes use of both formal and informal lines of communication The IETF makes use of both formal and informal lines of communication
to collaborate with other organizations within the multistakeholder to collaborate with other organizations within the multistakeholder
ecosystem. ecosystem.
>>> >>>
>>> "Maintain the security, stability, and resiliency of the >>> "Maintain the security, stability, and resiliency of the
>>> Internet DNS;" >>> Internet DNS;"
>>> >>>
IETF Response: IETF Response:
The DNS relies on some of the IETF protocol parameters registries. No changes are proposed in this document that affect the security,
As the current IANA functions operator, ICANN performs its task very stability, and resiliency of the DNS.
well, usually exceeding the service level agreement metrics.[METRICS]
Security, stability, and resiliency of the Internet DNS is best
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 parameters IETF standards and the associated IANA protocol parameters
registries. The current IANA protocol parameters registries system registries. The current IANA protocol parameters registries system
is meeting the needs of these global customers. This proposal is meeting the needs of these global customers. This proposal
continues to meet their needs by maintaining the existing processes continues to meet their needs by maintaining the existing processes
that have served them well in the past. that have served them well in the past.
>>> >>>
skipping to change at page 18, line 5 skipping to change at page 18, line 22
members of the community over many years. The initial version of members of the community over many years. The initial version of
this document was developed collaboratively through both the IAB IANA this document was developed collaboratively through both the IAB IANA
Strategy Program and the IETF IANAPLAN WG. Particular thanks go to Strategy Program and the IETF IANAPLAN WG. Particular thanks go to
Jari Arkko, John Klensin, Andrei Robachevsky, Andrew Sullivan, Leslie Jari Arkko, John Klensin, Andrei Robachevsky, Andrew Sullivan, Leslie
Daigle, Marc Blanchet, Barry Leiba, Brian Carpenter, Greg Wood, John Daigle, Marc Blanchet, Barry Leiba, Brian Carpenter, Greg Wood, John
Curran, Milton Mueller, Alissa Cooper, Andrei Robachevsky, and Curran, Milton Mueller, Alissa Cooper, Andrei Robachevsky, and
Suzanne Woolf. Suzanne Woolf.
7. Informative References 7. Informative References
[I-D.leiba-cotton-iana-5226bis]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", draft-
leiba-cotton-iana-5226bis-11 (work in progress), November
2014.
[METRICS] , "Performance Standards Metrics Report", , [METRICS] , "Performance Standards Metrics Report", ,
<http://www.iana.org/performance/metrics>. <http://www.iana.org/performance/metrics>.
[MOUSUP] , "Supplements to RFC 2860 (the Memorandum of [MOUSUP] , "Supplements to RFC 2860 (the Memorandum of
Understanding between the IETF and ICANN)", , Understanding between the IETF and ICANN)", ,
<http://iaoc.ietf.org/contracts.html>. <http://iaoc.ietf.org/contracts.html>.
[NTIA-Contract] [NTIA-Contract]
, "The NTIA Contract with ICANN", , <http:// , "The NTIA Contract with ICANN", , <http://
www.ntia.doc.gov/files/ntia/publications/ www.ntia.doc.gov/files/ntia/publications/
skipping to change at page 19, line 49 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 -03 to -04 A.1. Changes from -04 to -05
o Change to simpler text for answer about stability and security.
o Mention of RFC 5226bis.
A.2. 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.2. Changes from -02 to -03 A.3. 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 20, line 33 skipping to change at page 21, line 11
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.3. Changes from -01 to -02 A.4. 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.4. Changes from -00 to -01 A.5. 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. 17 change blocks. 
31 lines changed or deleted 41 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/