idnits 2.17.1
draft-ietf-ianaplan-icg-response-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 2 instances of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 06, 2014) is 3490 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'XXX' is mentioned on line 214, but not defined
-- Duplicate reference: RFC2860, mentioned in 'RFC2860', was also mentioned
in 'MOUSUP'.
-- Obsolete informational reference (is this intentional?): RFC 3777
(Obsoleted by RFC 7437)
-- Obsolete informational reference (is this intentional?): RFC 4071
(Obsoleted by RFC 8711)
-- Obsolete informational reference (is this intentional?): RFC 5226
(Obsoleted by RFC 8126)
-- Obsolete informational reference (is this intentional?): RFC 6220
(Obsoleted by RFC 8722)
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 IANAPLAN E. Lear, Ed.
3 Internet-Draft R. Housley, Ed.
4 Intended status: Informational October 06, 2014
5 Expires: April 09, 2015
7 Draft Response to the Internet Coordination Group Request for Proposals
8 on IANA
9 draft-ietf-ianaplan-icg-response-00
11 Abstract
13 This document contains the a draft response to a request for
14 proposals from the IANA Stewardship Transition Coordination Group
15 regarding the protocol parameters registries. It is meant to be
16 included in an aggregate proposal that also includes contributions
17 covering names and addresses that will be submitted from their
18 respective operational communities. The IETF community is invited to
19 comment and propose changes to this document.
21 Status of This Memo
23 This Internet-Draft is submitted in full conformance with the
24 provisions of BCP 78 and BCP 79.
26 Internet-Drafts are working documents of the Internet Engineering
27 Task Force (IETF). Note that other groups may also distribute
28 working documents as Internet-Drafts. The list of current Internet-
29 Drafts is at http://datatracker.ietf.org/drafts/current/.
31 Internet-Drafts are draft documents valid for a maximum of six months
32 and may be updated, replaced, or obsoleted by other documents at any
33 time. It is inappropriate to use Internet-Drafts as reference
34 material or to cite them other than as "work in progress."
36 This Internet-Draft will expire on April 09, 2015.
38 Copyright Notice
40 Copyright (c) 2014 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (http://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Simplified BSD License text as described in Section 4.e of
50 the Trust Legal Provisions and are provided without warranty as
51 described in the Simplified BSD License.
53 Table of Contents
55 1. IETF Introduction . . . . . . . . . . . . . . . . . . . . . . 2
56 2. The Formal RFP Response . . . . . . . . . . . . . . . . . . . 3
57 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
59 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
60 6. Informative References . . . . . . . . . . . . . . . . . . . 18
61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
63 1. IETF Introduction
65 In March of 2014 the U.S. National Telecommunications & Information
66 Administration (NTIA) announced its intent to transition oversight of
67 Internet Assigned Numbers Authority (IANA) functions. In that
68 announcement, NTIA asked the Internet Corporation for Assigned Names
69 and Numbers (ICANN) to establish a process to deliver a proposal for
70 transition. As part of that process, the IANA Stewardship Transition
71 Coordination Group (ICG) was formed. They solicited proposals
72 regarding the respective functions that IANA performs, in order that
73 they may put forth a proposal to the NTIA.
75 While there are interactions between all of the IANA functions and
76 IETF standards, this document specifically addresses the protocol
77 registries function. Section 1 (this section) contains an
78 introduction that is sourced solely within the IETF. Section 2
79 contains the questionnaire that was written by the ICG and a formal
80 response by the IETF. Because much of this memo is taken from a
81 questionnaire we have quoted questions with ">>> " and we have
82 prefaced answers to questions being asked with "IETF Response:".
83 Note that there are small changes to the content of the questions
84 asked in order to match the RFC format.
86 As if to demonstrate the last point, the following text was included
87 in a footnote in the original propsoal.
89 In this RFP, "IANA" refers to the functions currently specified in
90 the agreement between NTIA and ICANN [http://www.ntia.doc.gov/page/
91 iana-functions-purchase-order] as well as any other functions
92 traditionally performed by the IANA functions operator. SAC-067
93 [https://www.icann.org/en/system/files/files/sac-067-en.pdf] provides
94 one description of the many different meanings of the term "IANA" and
95 may be useful reading in addition to the documents constituting the
96 agreement itself.
98 2. The Formal RFP Response
100 Introduction
102 NOTE: This section is taken in its entirety from the questionnaire
103 dated 8 September 2014.
105 Under the IANA Stewardship Transition Coordination Group (ICG)
106 Charter [ICG-CHARTER], the ICG has four main tasks:
108 (i) Act as liaison to all interested parties in the IANA
109 stewardship transition, including the three "operational
110 communities" (i.e., those with direct operational or service
111 relationships with the IANA functions operator; namely names,
112 numbers, protocol parameters). This task consists of:
114 a. Soliciting proposals from the operational communities
115 b. Soliciting the input of the broad group of communities
116 affected by the IANA functions
117 (ii) Assess the outputs of the three operational communities
118 for compatibility and interoperability
119 (iii) Assemble a complete proposal for the transition
120 (iv) Information sharing and public communication
122 This Request for Proposals (RFP) addresses task (i) of the ICG
123 Charter. This RFP does not preclude any form of input from the non-
124 operational communities.
126 0. Complete Formal Responses
128 The IANA Stewardship Transition Coordination Group (ICG) seeks
129 complete formal responses to this RFP from the "operational
130 communities" of IANA (i.e., those with direct operational or service
131 relationships with the IANA functions operator, in connection with
132 names, numbers, or protocol parameters).
134 Proposals are expected to enjoy a broad consensus of support from all
135 interested parties. During the development of their proposals, the
136 operational communities are requested to consult and work with other
137 affected parties. Likewise, in order to help the ICG maintain its
138 light coordination role, all other affected parties are strongly
139 encouraged to participate in community processes.
141 The following link provides information about ongoing community
142 processes and how to participate in them, and that will continue to
143 be updated over time:
145 https://www.icann.org/en/stewardship/community
147 Communities are asked to adhere to open and inclusive processes in
148 developing their responses, so that all community members may fully
149 participate in and observe those processes. Communities are also
150 asked to actively seek out and encourage wider participation by any
151 other parties with interest in their response.
153 A major challenge of the ICG will be to identify and help to
154 reconcile differences between submitted proposals, in order to
155 produce a single plan for the transition of IANA stewardship.
156 Submitted Proposals should therefore focus on those elements that are
157 considered to be truly essential to the transition of their specific
158 IANA functions.
160 The target deadline for all complete formal responses to this RFP is
161 15 January 2015.
163 I. Comments
165 While the ICG is requesting complete formal proposals from the
166 operational communities only, and that all interested parties get
167 involved as early as possible in the relevant community processes,
168 some parties may choose to provide comments directly to the ICG about
169 specific aspects of particular proposals, about the community
170 processes, or about the ICG's own processes. Comments may be
171 directly submitted to the ICG any time via email to icg-
172 forum@icann.org. Comments will be publicly archived at .
175 Commenters should be aware that ICG will direct comments received to
176 the relevant operational communities if appropriate. The ICG will
177 review comments received as time and resources permit and in
178 accordance with the overall timeline for the transition. That is,
179 comments received about specific proposals may not be reviewed until
180 those proposals have been submitted to the ICG. The ICG may
181 establish defined public comment periods about specific topics in the
182 future, after the complete formal responses to the RFP have been
183 received.
185 Required Proposal Elements
187 The ICG encourages each community to submit a single proposal that
188 contains the elements described in this section.
190 Communities are requested to describe the elements delineated in the
191 sections below in as much detail possible, and according to the
192 suggested format/structure, to allow the ICG to more easily
193 assimilate the results. While each question is narrowly defined to
194 allow for comparison between answers, respondents are encouraged to
195 provide further information in explanatory sections, including
196 descriptive summaries of policies/practices and associated references
197 to source documents of specific policies/practices. In this way, the
198 responses to the questionnaire will be useful at the operational
199 level as well as to the broader stakeholder communities.
201 In the interest of completeness and consistency, proposals should
202 cross-reference wherever appropriate the current IANA Functions
203 Contract[NTIA-Contract] when describing existing arrangements and
204 proposing changes to existing arrangements.
206 >>>
207 >>> 0. Proposal Type
208 >>>
209 >>> Identify which category of the IANA functions this
210 >>> submission proposes to address:
211 >>>
213 IETF Response:
214 [XXX] Protocol Parameters
216 This response states the existing practice of the IETF, and also
217 represents the views of the Internet Architecture Board and the IETF.
219 >>>
220 >>> I. Description of Community's Use of IANA Functions
221 >>>
222 >>> This section should list the specific, distinct IANA services
223 >>> or activities your community relies on. For each IANA service
224 >>> or activity on which your community relies, please provide the
225 >>> following:
226 >>> A description of the service or activity.
227 >>>
229 IETF Response:
231 Many IETF protocols make use of commonly defined protocol parameters.
232 These parameters are used by implementers, who are the IETF's primary
233 users of the IETF standards and other documents. To ensure
234 consistent interpretation of these parameter values by independent
235 implementations, and to promote universal interoperability, these
236 IETF protocol specifications define and require globally available
237 registry containing the parameter values and a pointer to
238 documentation of the associated semantic intent. The IETF uses the
239 IANA protocol parameter registries to implement such registries.
241 >>>
242 >>> A description of the customer(s) of the service or activity.
243 >>>
245 IETF Response:
247 The customer of the IANA protocol parameters function is the Internet
248 Engineering Task Force (IETF).
250 The IETF is a global voluntary standards organization whose goal is
251 to make the Internet work better [RFC3595]. IETF standards are
252 published in the RFC series. The IETF is responsible for the key
253 standards that are used on the Internet today, including IP, TCP,
254 DNS, BGP, and HTTP, to name but a few.
256 The IETF operates an open and transparent manner [RFC6852]. The
257 processes that govern the IETF are also published in the RFC series.
258 The Internet Standards Process is documented in [RFC2026]. That
259 document explains not only how standards are developed, but also how
260 disputes about decisions are resolved. RFC 2026 has been amended a
261 number of times, and those amendments are indicated in [RFC-INDEX].
262 The standards process can be amended in the same manner that
263 standards are approved. That is, someone proposes a change by
264 submitting a temporary document known as an Internet-Draft, the
265 community discusses it, and if rough consensus can be found the
266 change is approved by the Internet Engineering Steering Group (IESG),
267 who also have day-to-day responsibility for declaring IETF consensus
268 on technical decisions, including those that affect IANA. Anyone may
269 propose a change during a Last Call, and anyone may participate in
270 the community discussion.
272 >>>
273 >>> What registries are involved in providing the service or
274 >>> activity.
275 >>>
277 IETF Response:
279 The protocol parameter registries are the product of IETF work.
280 Administration of the protocol parameter registries is the service
281 that is provide to the IETF.
283 >>>
284 >>> A description of any overlaps or interdependencies between your
285 >>> IANA requirements and the functions required by other customer
286 >>> communities
287 >>>
289 IETF Response:
291 It is important to note that the IETF includes anyone who wishes to
292 participate, including anyone from ICANN or the regional Internet
293 registries (RIRs), and many people from those organizations regularly
294 do.
296 o The IETF has specified a number of special use registries with
297 regard to domain names. These registries require coordination
298 with the Generic Names Support Organization (GNSO). We already
299 perform this coordination.[RFC6761]
301 o The IETF specifies the DNS protocol. From time to time there have
302 been and will be updates to that protocol. We will continue to
303 coordinate with ICANN regarding those changes.
305 o The IETF specifies minimum requirements for root servers. Should
306 those requirements change, we will inform ICANN.
308 o The routing architecture has evolved over time, and is expected to
309 continue to do so. Such evolution may have an impact on
310 appropriate IP address allocation strategies. As and when that
311 happens, we will consult with the RIR community, as we have done
312 in the past.
314 o The IETF has established registries with IANA for special IPv4 and
315 IPv6 assignments. These are specified in [RFC6890]. The IETF
316 coordinates such assignments with the RIRs.
318 o IETF standards changes may have impact on operations of RIRs and
319 service providers. A recent example is the expansion of the BGP
320 community field from 16 to 32 bits.[RFC6793] It is important to
321 note that this change occurred out of operational necessity, and
322 it demonstrated strong alignment between the RIRs and the IETF.
324 >>> III. Existing, Pre-Transition Arrangements
325 >>>
326 >>> This section should describe how existing IANA-related
327 >>> arrangements work, prior to the transition.
328 >>>
329 >>> A. Policy Sources
330 >>>
331 >>>
332 >>> This section should identify the specific source(s) of policy
333 >>> which must be followed by the IANA functions operator in its
334 >>> conduct of the services or activities described above. If there
335 >>> are distinct sources of policy or policy development for
336 >>> different IANA activities, then please describe these
337 >>> separately. For each source of policy or policy development,
338 >>> please provide the following:
339 >>>
340 >>> Which IANA service or activity (identified in Section I) is
341 >>> affected.
342 >>>
344 IETF Response: The protocol parameters registry.
346 >>>
347 >>> A description of how policy is developed and established and
348 >>> who is involved in policy development and establishment.
349 >>>
351 IETF Response:
353 Policy for overall management of the registries is stated in RFCs in
354 [RFC6220] and [RFC5226]. The first of these documents explains the
355 model for how the registries are to be operated, how policy is set,
356 and how oversight takes place. RFC 5226 specifies the policies that
357 specification writers may employ when they define new protocol
358 registries in the "IANA Considerations" section of each
359 specification. All policies at the IETF begin with a proposal in the
360 form of an Internet-Draft. Anyone may submit such a proposal. If
361 there is sufficient interest, the Internet Engineering Steering Group
362 may choose to create a working group or an Area Director may choose
363 to sponsor the draft. In either case, anyone may comment on the
364 proposal as it progresses. A proposal cannot be passed by the IESG
365 unless it enjoys sufficient community support as to indicate rough
366 consensus [RFC7282] In each case, a "Last Call" is made so that
367 there is notice of any proposed change to a policy or process.
368 Anyone may comment during a Last Call.
370 >>>
371 >>> A description of how disputes about policy are resolved.
372 >>>
374 IETF Response:
376 Most disputes are handled at the lowest level through the working
377 group and rough consensus processes. Should anyone disagree with any
378 action, Section 6.5 of [RFC2026] specifies a multi-level conflict
379 resolution and appeals process that includes the responsible Area
380 Director, the IESG, and the IAB. Should appeals be upheld, an
381 appropriate remedy is applied. In the case where an someone claims
382 that the procedures themselves are insufficient or inadequate in some
383 way to address a circumstance, one may appeal an IAB decision to the
384 Internet Society Board of Trustees.
386 >>>
387 >>> References to documentation of policy development and dispute
388 >>> resolution processes.
389 >>>
391 IETF Response: As mentioned above, [RFC2026] Section 6.5 specifies a
392 conflict resolution and appeals process. [RFC2418] specifies working
393 group procedures. Note that both of these documents have been
394 amended in later RFCs as indicated in the [RFC-INDEX]. Please also
395 see the references at the bottom of this document.
397 >>>
398 >>> B. Oversight and Accountability
399 >>>
400 >>> This section should describe all the ways in which oversight is
401 >>> conducted over IANA functions operator's provision of the
402 >>> services and activities listed in Section I and all the ways in
403 >>> which IANA functions operator is currently held accountab le for
404 >>> the provision of those services. For each oversight or
405 >>> accountability mechanism, please provide as many of the
406 >>> following as are applicable:
407 >>>
408 >>> Which IANA service or activity (identified in Section I) is
409 >>> affected.
410 >>>
412 IETF Response: the protocol parameters registries.
414 >>>
415 >>> If not all policy sources identified in Section II.A are
416 >>> affected, identify which ones are affected.
417 >>>
419 IETF Response: all policy sources relating to the protocol parameters
420 registry have been specified in II.A.
422 >>>
423 >>> A description of the entity or entities that provide oversight
424 >>> or perform accountability functions, including how individuals
425 >>> are selected or removed from participation in those entities.
426 >>>
428 IETF Response:
430 The Internet Architecture Board (IAB) is an oversight body of the
431 IETF whose responsibilities include, among other things, confirming
432 appointment of IESG members, managing appeals as discussed above,
433 management of certain domains, including .ARPA [RFC3172], and general
434 architectural guidance to the broader community. The IAB must
435 approve the appointment of an organization to act as IANA on behalf
436 of the IETF. The IAB is also responsible for establishing liaison
437 relationships with other orgnaizations on behalf of the IETF. The
438 IAB's charter is to be found in [RFC2850].
440 The IAB members are selected and may be recalled through a Nominating
441 Committee (NOMCOM) process, which is described in [RFC3777]. This
442 process provides for selection of active members of the community who
443 themselves agree upon a slate of candidates. Those candidates are
444 sent to the Internet Society Board of Trustees for confirmation. In
445 general, members serve for two years. The IAB selects its own chair.
447 The IAB provides oversight of the protocol parameter registries of
448 the IETF, and is responsible for selecting appropriate operator(s)
449 and related per-registry arrangements. Especially when relationships
450 among protocols call for it, many registries are operated by, or in
451 conjunction with, other bodies. Unless the IAB or IETF has concluded
452 that special treatment is needed, the operator for registries is
453 currently ICANN.
455 >>>
456 >>> A description of the mechanism (e.g., contract, reporting
457 >>> scheme, auditing scheme, etc.). This should include a
458 >>> description of the consequences of the IANA functions operator
459 >>> not meeting the standards established by the mechanism, the
460 >>> extent to which the output of the mechanism is transparent and
461 >>> the terms under which the mechanism may change.
462 >>>
464 IETF Response:
466 A memorandum of understanding (MoU) between ICANN and the IETF
467 community has been in place since 2000. It can be found in
468 [RFC2860]. The MoU defines the work to be carried out by the IANA
469 staff for the IETF and the Internet Research Task Force (IRTF), a
470 peer organization to the IETF that focuses on research. Each year a
471 service level agreement is negotiated that supplements the MoU.
473 Day-to-day administration and contract management is the
474 responsibility of the IETF Administrative Director (IAD). The IETF
475 Administrative Oversight Committee (IAOC) oversees the IAD. IAOC
476 members are appointed by the Internet Society Board of Trustees, the
477 IAB, the IESG, and the NOMCOM [RFC4071]. The IAOC works with ICANN
478 to establish annual IANA performance metrics and operational
479 procedures, and the resulting document is adopted as an supplement to
480 the MoU each year [MOUSUP].
482 To date there have been no unresolvable disputes or issues. In the
483 unlikely event that a more difficult situation should arise, the IAOC
484 and the IAB would engage ICANN management to address the matter. The
485 MoU also provides an option for either party to terminate the
486 arrangement with six months notice. Obviously such action would only
487 be undertaken after serious consideration.
489 >>>
490 >>> Jurisdiction(s) in which the mechanism applies and the legal
491 >>> basis on which the mechanism rests.
492 >>>
494 IETF Response
496 Because of the nature of the agreement, questions of jurisdiction are
497 immaterial.
499 >>>IV. Proposed changes to IANA Activities/Services
501 >>>
502 >>> This section should describe what changes your community is
503 >>> proposing to the arrangements listed in Section II.B in light of
504 >>> the transition. If your community is proposing to replace one or
505 >>> more existing arrangements with new arrangements, that
506 >>> replacement should be explained and all of the elements listed
507 >>> in Section II.B should be described for the new
508 >>> arrangements. Your community should provide its rationale and
509 >>> justification for the new arrangements.
510 >>>
511 >>> If your community's proposal carries any implications for
512 >>> existing policy arrangements described in Section II.A, those
513 >>> implications should be described here.
514 >>>
515 >>> If your community is not proposing changes to arrangements
516 >>> listed in Section II.B, the rationale and justification for that
517 >>> choice should be provided here.
518 >>>
520 IETF Response:
522 No changes are required, as over the years since the creation of
523 ICANN, the IETF, ICANN, and IAB have together created a system of
524 agreements, policies, and oversight mechanisms that covers what is
525 needed.
527 First and foremost, IANA protocol parameter registry updates will
528 continue to function day-to-day, as they have been doing for the last
529 decade or more. The IETF community is quite satisfied with the
530 current arrangement with ICANN. RFC 2860 remains in force and has
531 served the IETF community very well. RFC 6220 has laid out an
532 appropriate service description and requirements.
534 Discussions during IETF 89 in London led to the following guiding
535 principles for IAB efforts that impact IANA protocol parameter
536 registries. These principles must be taken together; their order is
537 not significant.
539 1. The IETF protocol parameter registry function has been and
540 continues to be capably provided by the Internet technical community.
542 The strength and stability of the function and its foundation within
543 the Internet technical community are both important given how
544 critical protocol parameters are to the proper functioning of IETF
545 protocols.
547 We think the structures that sustain the protocol parameter registry
548 function needs to be strong enough that they can be offered
549 independently by the Internet technical community, without the need
550 for backing from external parties. And we believe we largely are
551 there already, although the system can be strengthened further, and
552 continuous improvements are being made.
554 2. The protocol parameter registry function requires openness,
555 transparency, and accountability.
557 Existing documentation of how the function is administered and
558 overseen is good [RFC2860], [RFC6220]. Further articulation and
559 clarity may be beneficial. It is important that the whole Internet
560 community can understand how the function works, and that the
561 processes for registering parameters and holding those who oversee
562 the protocol parameter function accountable for following those
563 processes are understood by all interested parties. We are committed
564 to making improvements here if necessary.
566 3. Any contemplated changes to the protocol parameter registry
567 function should respect existing Internet community agreements.
569 The protocol parameter registry is working well. The existing
570 Memorandum of Understanding in RFC 2860 defines "the technical work
571 to be carried out by the Internet Assigned Numbers Authority on
572 behalf of the Internet Engineering Task Force and the Internet
573 Research Task Force." Any modifications to the protocol parameter
574 registry function should be made using the IETF process to update RFC
575 6220 and other relevant RFCs. Put quite simply: evolution, not
576 revolution.
578 4. The Internet architecture requires and receives capable service
579 by Internet registries.
581 The stability of the Internet depends on capable provision of not
582 just IETF protocol parameters, but IP numbers, domain names, and
583 other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined
584 protocols. Thus we expect the role of the IETF in standards
585 development, architectural guidance, and allocation of certain name/
586 number parameters to continue. IP multicast addresses and special-
587 use DNS names are two examples where close coordination is needed.
588 The IETF will continue to coordinate with ICANN, the RIRs, and other
589 parties that are mutually invested in the continued smooth operation
590 of the Internet registries. We fully understand the need to work
591 together.
593 5. The IETF will continue management of the protocol parameter
594 registry function as an integral component of the IETF standards
595 process and the use of resulting protocols.
597 RFC 6220 specifies the role and function of the protocol parameters
598 registry, which is critical to IETF standards processes and IETF
599 protocols. The IAB, on behalf of the IETF, has the responsibility to
600 define and manage the relationship with the protocol registry
601 operator role. This responsibility includes the selection and
602 management of the protocol parameter registry operator, as well as
603 management of the parameter registration process and the guidelines
604 for parameter allocation.
606 6. The protocol parameters registries are provided as a public
607 service.
609 Directions for the creation of protocol parameter registries and the
610 policies for subsequent additions and updates are specified in RFCs.
611 The protocol parameters registries are available to everyone, and
612 they are published in a form that allows their contents to be
613 included in other works without further permission. These works
614 include, but are not limited to, implementations of Internet
615 protocols and their associated documentation.
617 These principles will guide the IAB, IAOC, and the rest of the IETF
618 community as they work with ICANN to establish future IANA
619 performance metrics and operational procedures.
621 >>> IV Transition Implications
623 >>>
624 >>> This section should describe what your community views as the
625 >>> implications of the changes it proposed in Section III. These
626 >>> implications may include some or all of the following, or other
627 >>> implications specific to your community:
628 >>>
629 >>> o Description of operational requirements to achieve continuity
630 >>> of service and possible new service integration throughout
631 >>> the transition.
632 >>> o Risks to operational continuity
633 >>> o Description of any legal framework requirements in the
634 >>> absence of the NTIA contract
635 >>> o Description of how you have tested or evaluated the
636 >>> workability of any new technical or operational methods
637 >>> proposed in this document and how they compare to established
638 >>> arrangements.
639 >>>
641 IETF Response:
643 No structural changes are required. The principles listed above will
644 guide IAB, IAOC, and the rest of the IETF community as they work with
645 ICANN to establish future IANA performance metrics and operational
646 procedures, as they have in the past.
648 As no services are expected to change, no continuity issuees are
649 anticipated, and there are no new technical or operational methods
650 proposed by the IETF to test. The IETF leadership, ICANN, and the
651 RIRs maintain an ongoing informal dialog to spot any unforeseen
652 issues that might arise as a result of other changes.
654 >>>
655 >>> V. NTIA Requirements
656 >>>
657 >>> Additionally, NTIA has established that the transition proposal
658 >>> must meet the following five requirements:
659 >>>
660 >>> "Support and enhance the multistakeholder model;"
661 >>>
663 IETF Response:
665 Everyone is welcome to participate in IETF activities. The policies
666 and procedures are outlined in the documents we named above. In-
667 person attendance is not required for participation, and many people
668 participate in email discussions that have never attended an IETF
669 meeting. An email account is the only requirement to participate.
670 The IETF makes use of both formal and informal lines of communication
671 to collaborate with other organizations within the multistakeholder
672 ecosystem.
674 >>>
675 >>> "Maintain the security, stability, and resiliency of the
676 >>> Internet DNS;"
677 >>>
679 IETF Response:
681 The DNS relies on some of the IETF protocol parameters registries.
682 As the current IANA functions operator, ICANN performs its task very
683 well, usually exceeding the service level agreement metrics.[METRICS]
684 Security, stability, and resiliency of the Internet DNS is best
685 protected by maintaining the current service in its current form.
687 >>>
688 >>> "Meet the needs and expectation of the global customers and
689 >>> partners of the IANA services;"
690 >>>
692 IETF Response:
694 Implementers and their users from around the world make use of the
695 IETF standards and the associated IANA protocol parameter registries.
696 The current IANA protocol parameter registry system is meeting the
697 needs of these global customers. This proposal continues to meet
698 their needs by maintaining the existing processes that have served
699 them well in the past.
701 >>>
703 >>>
704 >>> "Maintain the openness of the Internet."
705 >>>
707 IETF Response:
709 This proposal maintains the existing open framework that allows
710 anyone to participate in the development of IETF standards, including
711 the IANA protocol parameter registry policies. Further, an
712 implementer anywhere in the world has full access to the protocol
713 specification published n the RFC series and the protocol parameter
714 registries published at iana.org. Those who require assignments in
715 the IANA protocol registries will continue to be able to do so, as
716 specified by the existing policies for those registries.
718 {We will have an open discussion, make changes based on that
719 discussion, and then conduct a Last Call to confirm that there is
720 rough consensus for the proposal.}
722 >>>
723 >>> VI. Community Process
724 >>>
725 >>> This section should describe the process your community used for
726 >>> developing this proposal, including:
727 >>>
728 >>> o The steps that were taken to develop the proposal and to
729 >>> determine consensus.
730 >>>
732 IETF Response:
734 The IESG established the IANAPLAN working group to develop this
735 response. Anyone was welcome to join the discussion and participate
736 in the development of this response. An open mailing list
737 (ianaplan@ietf.org) was associated with the working group. In
738 addition, IETF's IANA practices have been discussed in the broader
739 community, and all input is welcome.
741 >>>
742 >>> Links to announcements, agendas, mailing lists, consultations and
743 >>> meeting proceedings.
744 >>>
746 IETF Response: [xxx to be completed in more detail]
748 The following list is not exhaustive, as there have been many open
749 discussions about this transition within the IETF community in the
750 past few months.
752 Creation of an open mailing list to discuss the transition: http://w
753 ww.ietf.org/mail-archive/web/ietf-announce/current/msg12978.html
755 Announcement of a public session on the transition: http://
756 www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html
758 Announcement by the IESG of the intent to form a working group:
759 http://www.ietf.org/mail-archive/web/ietf-announce/current/
760 msg13170.html
762 >>>
763 >>> An assessment of the level of consensus behind your community's
764 >>> proposal, including a description of areas of contention or
765 >>> disagreement.
766 >>>
768 IETF Response: To be completed as the process progresses.
770 3. IANA Considerations
772 This memo is a response a request for proposals. No parameter
773 allocations or changes are sought.
775 4. Security Considerations
777 While the IANA framework has shown strong resiliency, the IETF will
778 continue to work with all relevant parties to facilitate improvements
779 in our standards.
781 5. Acknowledgments
783 This document does not define new processes, and so it seems we
784 acknowledge all of the preceding IAB members and members of the
785 community who developed the processes that we describe. The initial
786 version of this document was developed collaboratively through both
787 the IAB IANA Strategy Program and the IETF IANAPLAN WG. Particular
788 thanks go to Jari Arkko, John Klensin, Andrei Robachevsky, Andrew
789 Sullivan, Leslie Daigle, Barry Leiba, Brian Carpenter, and Greg Wood.
791 6. Informative References
793 [ICG-CHARTER]
794 , "The IANA Stewardship Transition Coordination Group
795 (ICG) Charter", , .
798 [METRICS] , "Performance Standards Metrics Report", ,
799 .
801 [MOUSUP] , "Supplements to RFC 2860 (the Memorandum of
802 Understanding between the IETF and ICANN)", ,
803 .
805 [NTIA-Contract]
806 , "The NTIA Contract with ICANN", , .
810 [RFC-INDEX]
811 RFC Editor, , "Index of all Requests for Comments", RFC
812 Index, August 2014.
814 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
815 3", BCP 9, RFC 2026, October 1996.
817 [RFC2418] Bradner, S., "IETF Working Group Guidelines and
818 Procedures", BCP 25, RFC 2418, September 1998.
820 [RFC2850] Internet Architecture Board and B. Carpenter, "Charter of
821 the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
822 May 2000.
824 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
825 Understanding Concerning the Technical Work of the
826 Internet Assigned Numbers Authority", RFC 2860, June 2000.
828 [RFC3172] Huston, G., "Management Guidelines & Operational
829 Requirements for the Address and Routing Parameter Area
830 Domain ("arpa")", BCP 52, RFC 3172, September 2001.
832 [RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", RFC
833 3595, September 2003.
835 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and
836 Recall Process: Operation of the Nominating and Recall
837 Committees", BCP 10, RFC 3777, June 2004.
839 [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF
840 Administrative Support Activity (IASA)", BCP 101, RFC
841 4071, April 2005.
843 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
844 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
845 May 2008.
847 [RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G.,
848 Internet Architecture Board, "Defining the Role and
849 Function of IETF Protocol Parameter Registry Operators",
850 RFC 6220, April 2011.
852 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
853 RFC 6761, February 2013.
855 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
856 Autonomous System (AS) Number Space", RFC 6793, December
857 2012.
859 [RFC6852] Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St.
860 Amour, "Affirmation of the Modern Paradigm for Standards",
861 RFC 6852, January 2013.
863 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
864 "Special-Purpose IP Address Registries", BCP 153, RFC
865 6890, April 2013.
867 [RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC
868 7282, June 2014.
870 Authors' Addresses
872 Eliot Lear (editor)
873 Richtistrasse 7
874 Wallisellen, ZH CH-8304
875 Switzerland
877 Phone: +41 44 878 9200
878 Email: lear@cisco.com
879 Russ Housley (editor)
880 918 Spring Noll Drive
881 Herndon, VA 20170
882 USA
884 Email: housley@vigilsec.com