-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-ietf-ianaplan-icg-response-06.xml
1589 lines (1528 loc) · 62.6 KB
/
draft-ietf-ianaplan-icg-response-06.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC3595 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3595.xml">
<!ENTITY RFC6852 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6852.xml">
<!ENTITY RFC2026 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml">
<!ENTITY RFC2418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2418.xml">
<!ENTITY RFC3777 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3777.xml">
<!ENTITY RFC2850 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2850.xml">
<!ENTITY RFC6220 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6220.xml">
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC2860 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2860.xml">
<!ENTITY RFC4071 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4071.xml">
<!ENTITY RFC6698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
<!ENTITY RFC3172 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3172.xml">
<!ENTITY RFC6793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6793.xml">
<!ENTITY RFC7282 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7282.xml">
<!ENTITY RFC6761 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6761.xml">
<!ENTITY RFC6890 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6890.xml">
<!ENTITY RFC3307 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3307.xml">
<!ENTITY RFC5771 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5771.xml">
<!ENTITY RFC7020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7020.xml">
<!ENTITY RFC7249 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7249.xml">
<!ENTITY RFC4193 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml">
<!ENTITY RFC2870 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2870.xml">
<!ENTITY I-D.leiba-cotton-iana-5226bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.leiba-cotton-iana-5226bis">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<rfc ipr="trust200902" docName="draft-ietf-ianaplan-icg-response-06" category="info">
<front>
<title abbrev="IANA ICG Response">
Draft Response to the Internet Coordination Group Request for
Proposals on the IANA protocol parameters registries
</title>
<author fullname="Eliot Lear" initials="E." surname="Lear" role="editor">
<organization></organization>
<address>
<postal>
<street>Richtistrasse 7</street>
<city>Wallisellen</city>
<code>CH-8304</code>
<region>ZH</region>
<country>Switzerland</country>
</postal>
<phone>+41 44 878 9200</phone>
<email>[email protected]</email>
</address>
</author>
<author fullname="Russ Housley" initials="R." surname="Housley"
role="editor">
<organization></organization>
<address>
<postal>
<street>918 Spring Noll Drive</street>
<city>Herndon</city>
<region>VA</region>
<code>20170</code>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date />
<workgroup>IANAPLAN</workgroup>
<abstract>
<t>
This document contains the IETF response to a request for
proposals from the IANA Stewardship Transition Coordination
Group regarding the protocol parameters registries. It is
meant to be included in an aggregate proposal that also
includes contributions covering domain names and numbering
resources that will be submitted from their respective
operational communities. The IETF community is invited to
comment and propose changes to this document.
</t>
</abstract>
</front>
<middle>
<section title="IETF Introduction">
<t>In March of 2014 the U.S. National Telecommunications &
Information Administration (NTIA) announced its intent to
transition oversight of Internet Assigned Numbers Authority
(IANA) functions. In that announcement, NTIA asked the Internet
Corporation for Assigned Names and Numbers (ICANN) to establish
a process to deliver a proposal for transition. As part of that
process, the IANA Stewardship Transition Coordination Group
(ICG) was formed. The charter for the ICG can be found in
<xref target="ICG-Charter"/>. They solicited proposals regarding
post-transition arrangements from the three functional areas in
order to put forth a proposal to the NTIA.
The final request for proposal (RFP) can be found
in <xref target="ICG-RFP"/>.
</t>
<t>While there are interactions between all of the IANA
functions and IETF standards, this document specifically
addresses the protocol parameters registries function. Section 1
(this section) contains an introduction that is sourced solely
within the IETF. Section 2 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 questionnaire we have quoted
questions with ">>> " and we have prefaced answers to
questions being asked with "IETF Response:". Note that there
are small changes to the content of the questions asked in order
to match the RFC format.
</t>
<t>As if to demonstrate the last point, the following text was
included in a footnote in the original RFP:
</t>
<t>
In this RFP, "IANA" refers to the functions currently
specified in the agreement between NTIA and ICANN
[http://www.ntia.doc.gov/page/iana-functions-purchase-order] as
well as any other functions traditionally performed by the IANA
functions operator. SAC-067
[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 may be useful reading in addition to the
documents constituting the agreement itself.
</t>
</section>
<section title="The Formal RFP Response">
<t>
The entire Request for Proposals, including introduction, can be found
in <xref target="ICG-RFP"/>.
</t>
<t>
<figure><artwork><![CDATA[
>>>
>>> 0. Proposal Type
>>>
>>> Identify which category of the IANA functions this
>>> submission proposes to address:
>>>
IETF Response:
[XXX] Protocol Parameters
]]></artwork></figure>
</t>
<t>
This response states the existing practice of the IETF, and
also represents the views of the Internet Architecture Board
and the IETF.
</t>
<t>
<figure><artwork><![CDATA[
>>>
>>> I. Description of Community’s Use of IANA Functions
>>>
>>> This section should list the specific, distinct IANA services
>>> or activities your community relies on. For each IANA service
>>> or activity on which your community relies, please provide the
>>> following:
>>> A description of the service or activity.
>>>
]]></artwork></figure>
</t>
<t>
IETF Response:
</t>
<t>Many IETF protocols make use of commonly defined protocol
parameters. These parameters are used by implementers, who are
the primary users of the IETF standards and other
documents. To ensure consistent interpretation of these
parameter values by independent implementations, and to
promote universal interoperability, these IETF protocol
specifications define and require globally available registries
containing the parameter values and a pointer to any
associated documentation. The IETF uses the IANA
protocol parameters registries to store this information in a
public location. The IETF community presently accesses the
protocol parameter registries via references based on iana.org
domain name, and makes use of the term "IANA" in the protocol
parameter registry processes <xref target="RFC5226"/>.
</t>
<t>ICANN currently operates the .ARPA top level domain on
behalf of the Internet Architecture Board (IAB). This zone is
used for certain Internet infrastructure services that are
delegated beneath it. We consider .ARPA part of the protocol
parameters registries for purposes of this response.
</t>
<t>
<figure><artwork><![CDATA[
>>>
>>> A description of the customer(s) of the service or activity.
>>>
]]></artwork></figure>
</t>
<t>IETF Response:</t>
<t>
The IANA protocol parameters registries operator maintains the
protocol parameters registries for the IETF in conformance with
all relevant IETF policies, in accordance with the Memorandum
of Understanding <xref target="RFC2860"/> and associated
supplemental agreements that include service level agreements
(SLAs) established between the IETF and
ICANN <xref target="MOUSUP"/>.
</t>
<t>
The IETF is a global organization that produces voluntary standards,
whose goal is to make the
Internet work better <xref target="RFC3595" />. IETF
standards are published in the RFC series. The IETF is
responsible for the key standards that are used on the
Internet today, including IP, TCP, DNS, BGP, and HTTP, to name
but a few.
</t>
<t>
The IETF operates in an open and transparent manner
<xref target="RFC6852" />. The processes that govern the IETF
are also published in the RFC series. The Internet Standards
Process is documented in <xref target="RFC2026" />. That
document explains not only how standards are developed, but
also how disputes about decisions are resolved. RFC 2026 has
been amended a number of times, and those amendments are
indicated in <xref target="RFC-INDEX" />. The standards
process can be amended in the same manner that standards are
approved. That is, someone proposes a change by submitting a
temporary document known as an Internet-Draft, the community
discusses it, and if rough consensus can be found the change
is approved by the Internet Engineering Steering Group (IESG),
who also have day-to-day responsibility for declaring IETF
consensus on technical decisions, including those that affect
the IANA protocol parameters registries. Anyone may propose a
change during a Last Call, and anyone may participate in the
community discussion.
</t>
<t>
<figure><artwork><![CDATA[
>>>
>>> What registries are involved in providing the service or
>>> activity.
>>>
]]></artwork></figure>
</t>
<t>
IETF Response:
</t>
<t>The protocol parameters registries are the product of IETF
work. These also include the top-level registry for the entire IP
address space and some of its sub-registries, autonomous system
number space, and a number of special use registries with regard to
domain names. For more detail please refer to the documentation in
the "overlaps or interdependencies" section.</t>
<t>
Administration of the protocol parameters registries is the service
that is provided to the IETF.
</t>
<t>
<figure><artwork><![CDATA[
>>>
>>> A description of any overlaps or interdependencies between your
>>> IANA requirements and the functions required by other customer
>>> communities
>>>
]]></artwork></figure>
</t>
<t>
IETF Response:
</t>
<t>In this context, the IETF considers "overlap" to be where
there is in some way shared responsibility for a single registry
across multiple organizations. In this sense, there is no
overlap between organizations because responsibility for each
registry is carefully delineated. There are, however, points of
interaction between other organizations, and a few cases where we
may further define the scope of a registry for technical
purposes. This is the case with both names and numbers, as
described in the paragraphs below. In all cases, the IETF
coordinates with the appropriate organizations.
</t>
<t>
It is important to note that the IETF includes anyone who
wishes to participate. Staff and participants
from ICANN or the Regional Internet Registries (RIRs) regularly
participate in IETF activities.
</t>
<t></t>
<t>
<list style="symbols">
<t>
The IETF has specified a number of special use registries
with regard to domain names. These registries require
coordination with ICANN as the policy authority for the DNS
root, including community groups that are responsible for
ICANN policy on domain names such as the Generic Names
Supporting Organization (GNSO) and the Country Code Names
Supporting Organization (ccNSO).
There are already mechanisms in place to perform this
coordination, and the capacity to modify them to meet new
conditions as they might arise. <xref target="RFC6761" />
</t>
<t>
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 will broadly consult the operational
community about the impact of those changes, as we have done
in the past.
</t>
<t>
The IETF specifies minimum requirements for root
servers. <xref target="RFC2870"/>
Those requirements are currently under review, in
consultations with the root server community.
</t>
<t>
The routing architecture has evolved over time, and is
expected to continue to do so. Such evolution may have an
impact on appropriate IP address allocation strategies. As
and when that happens, we will consult with the RIR
community, as we have done in the past.
</t>
<t>
The IETF is responsible for policy relating to the entire IP
address space and AS number space. Through the IANA
protocol parameters registries, the IETF delegates unicast
IP address and AS number ranges to the RIR system
<xref target="RFC7020"/>,<xref target="RFC7249"/>. Special
address allocation, such as multicast and anycast addresses,
often require coordination. Another example of IP addresses
that are not administered by the RIR system is Unique Local
Addresses (ULAs) <xref target="RFC4193"/>, where local
networks employ a prefix that is not intended to be routed
on the public Internet. New special address allocations are
added, from time to time, related to the evolution of the
standards. In all cases, these special assignments are
listed in the IANA protocol paramters registries.</t>
<t>
The IETF maintains sub-registries for special IPv4 and IPv6
assignments. These are specified in
<xref target="RFC3307"/>, <xref target="RFC5771"/>, and
<xref target="RFC6890"/>. The IETF coordinates such
assignments with the RIRs.
</t>
<t>
IETF standards changes may have impact on operations of RIRs
and service providers. A recent example is the extensions
to BGP to carry the Autonomous System numbers as four-octet
entities <xref target="RFC6793"/>. It is important to note
that this change occurred out of operational necessity, and
it demonstrated strong alignment between the RIRs and the
IETF.
</t>
</list>
</t>
<t>
</t>
<t></t>
<t>>>> II. Existing, Pre-Transition Arrangements</t>
<t></t>
<t>
<figure><artwork><![CDATA[
>>>
>>> This section should describe how existing IANA-related
>>> arrangements work, prior to the transition.
>>>
>>> A. Policy Sources
>>>
>>>
>>> This section should identify the specific source(s) of policy
>>> which must be followed by the IANA functions operator in its
>>> conduct of the services or activities described above. If there
>>> are distinct sources of policy or policy development for
>>> different IANA activities, then please describe these
>>> separately. For each source of policy or policy development,
>>> please provide the following:
>>>
>>> Which IANA service or activity (identified in Section I) is
>>> affected.
>>>
]]></artwork></figure>
</t>
<t></t>
<t>IETF Response: The protocol parameters registries.</t>
<t></t>
<t><figure><artwork><![CDATA[
>>>
>>> A description of how policy is developed and established and
>>> who is involved in policy development and establishment.
>>>
]]></artwork></figure>
</t>
<t></t>
<t>
IETF Response:
</t>
<t>
Policy for overall management of the protocol parameters
registries is stated in <xref target="RFC6220" /> and
<xref target="RFC5226" />. The first of these documents
explains the model for how the registries are to be operated,
how policy is set, and how oversight takes place. RFC 5226
specifies the policies that specification writers may employ
when they define new protocol registries in the "IANA
Considerations" section of each specification. All policies
at the IETF begin with a proposal in the form of an
Internet-Draft. Anyone may submit such a proposal. If there
is sufficient interest, a working group whose scope includes
the proposed work may choose to adopt it, the IESG
may choose to create a working
group, or an Area Director may choose to sponsor the draft.
In any case, anyone may comment on the proposal as it
progresses. A proposal cannot be passed by the IESG unless it
enjoys sufficient community support as to indicate rough
consensus <xref target="RFC7282" />. In each case, a "Last
Call" is made so that there is notice of any proposed change
to a policy or process. Anyone may comment during a Last
Call. For example, this process is currently being used to
update RFC 5226
<xref target="I-D.leiba-cotton-iana-5226bis"/>.
</t>
<t></t>
<t><figure><artwork><![CDATA[
>>>
>>> A description of how disputes about policy are resolved.
>>>
]]></artwork></figure>
</t>
<t></t>
<t>IETF Response:
</t>
<t>Most disputes are handled at the lowest level through the working
group and rough consensus processes. Should anyone disagree with
any action, Section 6.5 of <xref target="RFC2026" /> specifies a
multi-level conflict resolution and appeals process that includes
the responsible Area Director, the IESG, and the IAB. Should
appeals be upheld, an appropriate remedy is applied. In the case
where someone claims that the procedures themselves are
insufficient or inadequate in some way to address a circumstance,
one may appeal an IAB decision to the Internet Society Board of
Trustees.
</t>
<t></t>
<t><figure><artwork><![CDATA[
>>>
>>> References to documentation of policy development and dispute
>>> resolution processes.
>>>
]]></artwork></figure>
</t>
<t>
IETF Response: As mentioned above, <xref target="RFC2026" />
Section 6.5 specifies a conflict resolution and appeals
process. <xref target="RFC2418" /> specifies working group
procedures. Note that both of these documents have been
amended in later RFCs as indicated in the
<xref target="RFC-INDEX" />. Please also see the references
at the bottom of this document.
</t>
<t></t>
<t><figure><artwork><![CDATA[
>>>
>>> B. Oversight and Accountability
>>>
>>> This section should describe all the ways in which oversight is
>>> conducted over IANA functions operator’s provision of the
>>> services and activities listed in Section I and all the ways in
>>> which IANA functions operator is currently held accountab le for
>>> the provision of those services. For each oversight or
>>> accountability mechanism, please provide as many of the
>>> following as are applicable:
>>>
>>> Which IANA service or activity (identified in Section I) is
>>> affected.
>>>
]]></artwork></figure>
</t>
<t>IETF Response: the protocol parameters registries.</t>
<t><figure><artwork><![CDATA[
>>>
>>> If not all policy sources identified in Section II.A are
>>> affected, identify which ones are affected.
>>>
]]></artwork></figure>
</t>
<t>IETF Response: all policy sources relating to the protocol
parameters registry are affected.
</t>
<t><figure><artwork><![CDATA[
>>>
>>> A description of the entity or entities that provide oversight
>>> or perform accountability functions, including how individuals
>>> are selected or removed from participation in those entities.
>>>
]]></artwork></figure>
</t>
<t>IETF Response:
</t><t>The Internet Architecture Board (IAB) is an oversight
body of the IETF whose responsibilities include, among other
things, confirming appointment of IESG members, managing
appeals as discussed above, management of certain domains,
including .ARPA <xref target="RFC3172" />, and general
architectural guidance to the broader community. The IAB
must approve the appointment of an organization to act as
IANA operator on behalf of the IETF. The IAB is also
responsible for establishing liaison relationships with
other organizations on behalf of the IETF. The IAB's
charter is to be found in <xref target="RFC2850" />.
</t>
<t>
The IAB members are selected and may be recalled through a
Nominating Committee (NOMCOM) process, which is described in
<xref target="RFC3777" />. This process provides for
selection of active members of the community who themselves
agree upon a slate of candidates. The active members are
chosen randomly from volunteers with a history of
participation in the IETF, with limits regarding having too
many active members with 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.
</t>
<t>The IAB provides oversight of the protocol parameters
registries of the IETF, and is responsible for selecting
appropriate operator(s) and related per-registry
arrangements. Especially when relationships among protocols
call for it, many registries are operated by, or in
conjunction with, other bodies. Unless the IAB or IETF has
concluded that special treatment is needed, the operator for
registries is currently ICANN.
</t>
<t><figure><artwork><![CDATA[
>>>
>>> A description of the mechanism (e.g., contract, reporting
>>> scheme, auditing scheme, etc.). This should include a
>>> description of the consequences of the IANA functions operator
>>> not meeting the standards established by the mechanism, the
>>> extent to which the output of the mechanism is transparent and
>>> the terms under which the mechanism may change.
>>>
]]></artwork></figure>
</t>
<t>
IETF Response:
</t>
<t>
A memorandum of understanding (MoU) between ICANN and the IETF
community has been in place since 2000. It can be found in
<xref target="RFC2860" />. The MoU defines the work to be
carried out by the IANA functions operator for the IETF and
the Internet Research Task Force (IRTF), a peer organization
to the IETF that focuses on research. Each year a service
level agreement is negotiated that supplements the MoU.
</t>
<t>
Day-to-day administration and contract management is the
responsibility of the IETF Administrative Director (IAD). The
IETF Administrative Oversight Committee (IAOC) oversees the
IAD. The members of the IAOC are also the trustees of the
IETF Trust, whose main purpose is to hold certain intellectual
property for the benefit of the IETF as a whole.
IAOC members are appointed by the Internet Society Board
of Trustees, the IAB, the IESG, and the NOMCOM
<xref target="RFC4071" />. The IAOC works with the IANA
functions operator to establish annual IANA performance
metrics <xref target="METRICS"/> and operational procedures,
and the resulting document
is adopted as an supplement to the MoU each year
<xref target="MOUSUP"/>. Starting from 2014, in accordance
with these supplements, an annual audit is performed to ensure that
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.
</t>
<t>
To date there have been no unresolvable disputes or issues.
In the unlikely event that a more difficult situation should arise,
the IAOC and the IAB would engage ICANN management to address
the matter. The MoU also provides an option for either party
to terminate the arrangement with six months notice. Obviously
such action would only be undertaken after serious
consideration.
</t>
<t><figure><artwork><![CDATA[
>>>
>>> Jurisdiction(s) in which the mechanism applies and the legal
>>> basis on which the mechanism rests.
>>>
]]></artwork></figure>
</t>
<t>IETF Response</t>
<t>
This mechanism is global in nature. The current agreement
does not specify a jurisdiction.
</t>
<t></t>
<t>>>>III. Proposed Post-Transition Oversight and
Accountability Arrangements</t>
<t></t>
<t><figure><artwork><![CDATA[
>>>
>>> This section should describe what changes your community is
>>> proposing to the arrangements listed in Section II.B in light of
>>> the transition. If your community is proposing to replace one or
>>> more existing arrangements with new arrangements, that
>>> replacement should be explained and all of the elements listed
>>> in Section II.B should be described for the new
>>> arrangements. Your community should provide its rationale and
>>> justification for the new arrangements.
>>>
>>> If your community’s proposal carries any implications for
>>> existing policy arrangements described in Section II.A, those
>>> implications should be described here.
>>>
>>> If your community is not proposing changes to arrangements
>>> listed in Section II.B, the rationale and justification for that
>>> choice should be provided here.
>>>
]]></artwork></figure>
</t>
<t>
IETF Response:
</t>
<t>
No major changes are required. Over the years since the creation of
ICANN, the IETF, ICANN, and IAB have together created a system of
agreements, policies, and oversight mechanisms that already cover what is
needed. This system has worked well without any operational
involvement from the NTIA. Therefore, no new organizaitons or
structures are needed.
</t><t>
IANA protocol parameters registry updates will continue to function
day-to-day, as they have been doing for the last decade or more. The
IETF community is quite satisfied with the current arrangement with
ICANN. RFC 2860 remains in force and has served the IETF community
very well. RFC 6220 has laid out an appropriate service description
and requirements.
</t><t>
However in the absence of the NTIA contract a few new arrangements may
be needed in order to ensure the IETF community's expectations are
met. Those expectations are the following:
<list style="symbols">
<t>
The protocol parameters registries are in the public domain. It is the
preference of the IETF community that all relevant parties acknowledge
that fact as part of the transition.
</t>
<t>
It is possible in the future that the operation of the protocol
parameters registries may be transitioned from ICANN to subsequent
operator(s). It is the preference of the IETF community that, as part
of the NTIA transition, ICANN acknowledge that it will carry out the
obligations established under C.7.3 and I.61 of the current IANA
functions contract between ICANN and the
NTIA <xref target="NTIA-Contract"/> to achieve a smooth transition
to subsequent operator(s), should the need arise. Furthermore, in
the event of a transition it is the expectation of the IETF
community that ICANN, the IETF, and subsequent operator(s) will
work together to minimize disruption in the use the protocol
parameters registries or other resources currently located at
iana.org.
</t>
</list>
</t>
<t>
Discussions during the IETF 89 meeting in London led to the
following guiding principles for IAB efforts that impact IANA
protocol parameter registries. These principles must be taken
together; their order is not significant.
</t>
<t>1. The IETF protocol parameters registries function has been and
continues to be capably provided by the Internet technical
community.
</t>
<t>
The strength and stability of the function and its foundation
within the Internet technical community are both important
given how critical protocol parameters are to the proper
functioning of IETF protocols.
</t>
<t>
We think the structures that sustain the protocol parameters
registries function need to be strong enough that they can be
offered independently by the Internet technical community,
without the need for backing from external parties. And we
believe we largely are there already, although the system can
be strengthened further, and continuous improvements are being
made.
</t>
<t></t>
<t>
2. The protocol parameters registries function requires openness,
transparency, and accountability.
</t>
<t>
Existing documentation of how the function is administered and
overseen is good <xref target="RFC2860" />,
<xref target="RFC6220" />. Further articulation and clarity
may be beneficial. It is important that the whole Internet
community can understand how the function works, and that the
processes for registering parameters and holding those who
oversee the protocol parameters function accountable for
following those processes are understood by all interested
parties. We are committed to making improvements here if
necessary.
</t>
<t></t>
<t>
3. Any contemplated changes to the protocol parameters registries
function should respect existing Internet community agreements.
</t>
<t>
The protocol parameters registries function is working well.
The existing Memorandum of Understanding in RFC 2860 defines
"the technical work to be carried out by the Internet Assigned
Numbers Authority on behalf of the Internet Engineering Task
Force and the Internet Research Task Force." Any
modifications to the protocol parameters registries function
should be made using the IETF process to update RFC 6220 and
other relevant RFCs. Put quite simply: evolution, not
revolution.
</t>
<t></t>
<t>
4. The Internet architecture requires and receives capable
service by Internet registries.
</t>
<t></t>
<t>
The stability of the Internet depends on capable provision of
not just IETF protocol parameters, but IP numbers, domain
names, and other registries. Furthermore, DNS and IPv4/IPv6
are IETF-defined protocols. Thus we expect the role of the
IETF in standards development, architectural guidance, and
allocation of certain name/number parameters to continue. IP
multicast addresses and special-use DNS names are two examples
where close coordination is needed. The IETF will continue to
coordinate with ICANN, the RIRs, and other parties that are
mutually invested in the continued smooth operation of the
Internet registries. We fully understand the need to work
together.
</t>
<t></t>
<t>
5. The IETF will continue management of the protocol
parameter registry function as an integral component of the IETF
standards process and the use of resulting protocols.
</t>
<t></t>
<t>
RFC 6220 specifies the role and function of the protocol
parameters registry, which is critical to IETF standards
processes and IETF protocols. The IAB, on behalf of the IETF,
has the responsibility to define and manage the relationship
with the protocol registry operator role. This responsibility
includes the selection and management of the protocol
parameter registry operator, as well as management of the
parameter registration process and the guidelines for
parameter allocation.
</t>
<t></t>
<t>
6. The protocol parameters registries are provided as a public
service.
</t>
<t></t>
<t>
Directions for the creation of protocol parameters registries
and the policies for subsequent additions and updates are
specified in RFCs. The protocol parameters registries are
available to everyone, and they are published in a form that
allows their contents to be included in other works without
further permission. These works include, but are not limited
to, implementations of Internet protocols and their associated
documentation.
</t>
<t>
These principles will guide the IAB, IAOC, and the rest of the
IETF community as they work with ICANN to establish future
IANA performance metrics and operational procedures.
</t>
<t></t>
<t>>>> IV Transition Implications</t>
<t></t>
<t><figure><artwork><![CDATA[
>>>
>>> This section should describe what your community views as the
>>> implications of the changes it proposed in Section III. These
>>> implications may include some or all of the following, or other
>>> implications specific to your community:
>>>
>>> o Description of operational requirements to achieve continuity
>>> of service and possible new service integration throughout
>>> the transition.
>>> o Risks to operational continuity
>>> o Description of any legal framework requirements in the
>>> absence of the NTIA contract
>>> o Description of how you have tested or evaluated the
>>> workability of any new technical or operational methods
>>> proposed in this document and how they compare to established
>>> arrangements.
>>>
]]></artwork></figure>
</t>
<t>IETF Response:</t>
<t>
No structural changes are required. The principles listed
above will guide IAB, IAOC, and the rest of the IETF
community as they work with ICANN to establish future IANA
performance metrics and operational procedures, as they have
in the past.
</t>
<t>As no services are expected to change, no continuity issues are
anticipated, and there are no new technical or operational methods
proposed by the IETF to test. The IETF leadership, ICANN, and the
RIRs maintain an ongoing informal dialog to spot any unforeseen issues
that might arise as a result of other changes.</t>
<t>What is necessary as part of transition is the completion of
any supplemental agreement(s) necessary to achieve the requirements
outlined in our response in Section III of this RFP.
</t>
<t></t>
<t><figure><artwork><![CDATA[
>>>
>>> V. NTIA Requirements
>>>
>>> Additionally, NTIA has established that the transition proposal
>>> must meet the following five requirements:
>>>
>>> "Support and enhance the multistakeholder model;"
>>>
]]></artwork></figure>
</t>
<t>IETF Response:</t>
<t>
Everyone is welcome to participate in IETF activities. The
policies and procedures are outlined in the documents we named
above. In-person attendance is not required for
participation, and many people participate in email
discussions that have never attended an IETF meeting. An
email account is the only requirement to participate. The
IETF makes use of both formal and informal lines of
communication to collaborate with other organizations within
the multistakeholder ecosystem.
</t>
<t></t>
<t><figure><artwork><![CDATA[
>>>
>>> "Maintain the security, stability, and resiliency of the
>>> Internet DNS;"
>>>
]]></artwork></figure>
</t>
<t></t>
<t>IETF Response:</t>
<t>
No changes are proposed in this document that affect the security,
stability, and resiliency of the DNS.
</t>
<t></t>
<t><figure><artwork><![CDATA[
>>>
>>> "Meet the needs and expectation of the global customers and
>>> partners of the IANA services;"
>>>
]]></artwork></figure>
</t>
<t></t>
<t>IETF Response:</t>
<t>
Implementers and their users from around the world make use of
the IETF standards and the associated IANA protocol parameters
registries. The current IANA protocol parameters registries
system is meeting the needs of these global customers. This
proposal continues to meet their needs by maintaining the
existing processes that have served them well in the past.
</t>
<t></t>
<t>
>>>
</t>
<t>
<figure><artwork><![CDATA[
>>>
>>> "Maintain the openness of the Internet."
>>>
]]></artwork></figure>
</t>
<t></t>
<t>IETF Response:</t>
<t>
This proposal maintains the existing open framework that
allows anyone to participate in the development of IETF
standards, including the IANA protocol parameters registries
policies. Further, an implementer anywhere in the world has
full access to the protocol specification published in the RFC
series and the protocol parameters registries published at
iana.org. Those who require assignments in the IANA protocol
registries will continue to be able to do so, as specified by
the existing policies for those registries.
</t>
<t></t>
<t><figure><artwork><![CDATA[
>>>
>>> VI. Community Process
>>>
>>> This section should describe the process your community used for
>>> developing this proposal, including:
>>>
>>> o The steps that were taken to develop the proposal and to
>>> determine consensus.
>>>
]]></artwork></figure>
</t>
<t>IETF Response:
</t>
<t>
The IESG established the IANAPLAN working group to develop
this response. Anyone was welcome to join the discussion and
participate in the development of this response. An open
mailing list ([email protected]) was associated with the
working group. In addition, IETF’s IANA practices have been
discussed in the broader community, and all input is welcome.
</t>
<t><figure><artwork><![CDATA[
>>>
>>> Links to announcements, agendas, mailing lists, consultations and
>>> meeting proceedings.
>>>
]]></artwork></figure>
</t>
<t>
IETF Response:
</t>
<t>
The following list is not exhaustive, as there have been many open
discussions about this transition within the IETF community in the
past few months.
</t>
<t>
<list style="hanging">
<t hangText="Creation of an open mailing list to discuss the transition:">
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg12978.html
</t>
<t hangText="Announcement of a public session on the transition:">
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13028.html
</t>
<t hangText="Announcement by the IESG of the intent to form a working group:">
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13170.html
</t>
<t hangText="The working group discussion">
http://www.ietf.org/mail-archive/web/ianaplan/current/maillist.html
</t>
<t hangText="Working group last call">
http://www.ietf.org/mail-archive/web/ianaplan/current/msg00760.html
</t>
</list>
</t>
<t>
<figure><artwork><![CDATA[
>>>
>>> An assessment of the level of consensus behind your community’s
>>> proposal, including a description of areas of contention or
>>> disagreement.
>>>
]]></artwork></figure>
</t>
<t>IETF Response: To be completed as the process progresses.
</t>
</section>
<section title="IANA Considerations">
<t>
This memo is a response a request for proposals. No
parameter allocations or changes are sought.
</t>
</section>
<section title="Security Considerations">
<t>
While the agreement, supplements, policies, and procedures around
the IANA function have shown strong resiliency, the IETF will
continue to work with all relevant parties to facilitate
improvements while maintaining availability of the IANA registries.
</t>
</section>
<section title="IAB Note">
<t>This section to be filled in by the IAB.
</t>
</section>
<section title="Acknowledgments">
<t>
</t>
<t>
This document describes processes that have been developed by
many members of the community over many years. The initial
version of this document was developed collaboratively through
both the IAB IANA Strategy Program and the IETF IANAPLAN WG.